标签: database-design

我已经了解了对象角色建模,但没有了解对象关系映射,我想知道它们是否有两种方法可以做同样的事情,有哪些优点和缺点？对我来说,对象角色建模更有意义.如果可以比较它们,你能做一个简短但易于理解的比较.干杯

关于如何设计参数表,我很怀疑...

1. 你认为让html包含网络应用程序的pks是一种不好的做法吗？我认为是,我建议使用guids代替pks.
2. 你知道任何与参数表设计有关的模式吗？通常我会在一些数据库设计中找到一种参数数据表(即性别表,国家表......等).我更喜欢只有一个带有所有参数的表和一个带有键的列来从上层引用它们.
3. 您如何看待源文件与参数表具有相同的信息？我已经看到一些项目的源代码与每个与参数相关的pk ...这是一个好习惯吗？
4. 您认为创建缓存方案以保留参数数据是否相关？

谢谢!

注意:这个问题扩展了这一点.

我正在建立一个商业网站，并且一直在研究不同的方式来展示具有变体的产品。我正在尝试对隐形眼镜进行此操作，并想知道最好的方法是什么。

产品可以很简单，例如没有变体的镜片盒或镜片溶液，或者对于隐形眼镜，每个镜片最多可以有三个可配置的变体，具体取决于镜片，用于处方（例如功率，基弧、直径）。

在我的结构中，我有简单的产品，只是一个产品，没有父产品。隐形眼镜将存储为产品，每个变体将存储为引用其父代的单独产品，并且变体本身将使用 products_variants 表进行链接。

我有这样的结构：

products
- id
- parent_id
- name
- price
- type_id
- brand_id

type
- id
- name

brand
- id
- name

product_variant_group
- id
- name

product_variant_value
- id
- product_variant_group_id
- value

products_variants (isCrossRef = true for Propel relationships)
- id
- product_id
- product_variant_value_id

我的代码已经很慢了，我什至还没有开始构建选择框来选择处方。

public function getPossibleVariants($productId)
    {
        $product = ProductQuery::create()->findPk($productId);
        $children = $product->getChildren();

        $options = array();

        foreach ($children as $child) {
            if ($child->countProductsVariantss()) {
                $variants = $child->getProductVariantValues();

                foreach …

我对 MySQL 中的订单表设计有疑问。我有 ORDERS 表

Order_id | Customer_id | Total_Price | 
--------------------------------------

在另一边我有桌子 PRODUCT

Product_id | Product_name | available_amount 
------------------------------------------

一个订单可以包含多个不同的产品。那么，如何更改或更新我的数据库设计，以便我可以有效地访问包含所有产品的任何订单？我应该创建单独的表名 Order_details 吗？你能帮我么？

我需要一个软件或在线网站，通过它我可以从我现有的数据库或脚本生成 ER 图表。请帮帮我。

我正在构建一个具有以下两个表的 Postgres 数据库：

项目（id、startDate 等...）和员工（id、name 等...）

我想跟踪员工为项目添加的贡献类型。例如，员工#1 可能是项目 1 的“工程师”和项目 2 的“经理”。我也不希望限制员工可以对某个项目做出的贡献数量。因此，员工#1 可以是单个项目的“工程师”和“经理”。

我的第一直觉只是在两个标题为 ProjectEmployees 或其他东西之间建立多对多关系，并将 projectId、employeeId 和tributionType 存储为一个字符串，该字符串只会从枚举中获取值，而不必处理拼写错误或任何相关问题。

我的主要问题是这是否是一种不好的做法。我的另一个想法是将每种贡献类型拆分到自己的表中。因此，不是 EmployeeProjects 表，而是诸如 ProjectEngineers、ProjectManagers 等的表……并且不是将贡献类型存储为列，而是隐式在我正在使用的表中，并且该表只需要存储项目 ID 和员工 ID。该数据库中有更多的表具有类似的关系，其中不同表之间存在多对多关系，但每个关系可能是许多“类型”关系中的一种。对于每种类型的关系，将所有这些都拆分为单独的表是否更明智？或者像我的第一个想法一样在更通用的表中跟踪关系类型更好吗？

我想要的结果是能够有效地查看员工参与的所有项目贡献（和类型），以及查看项目的所有贡献者 + 贡献者类型。

在 Sql Server 中有 sys Schema。sys.Columns, sys.Tables. 我有一个通用表，需要将其重命名为 SysUsers、SysRoles 等。

这样做可以吗？我不会使用 Sys 架构。我只是在表前加上Sys 我发现 SQL Server 本身通常会这样做

select * FROM SysColumns      // NOTE its not sys.Columns

实现多级层次结构,以便超级用户还拥有子用户拥有的所有权限,这意味着超级用户也可以管理子用户作业.

假设在应用程序中可以有N个用户层次结构......

• 超级用户

  • 子用户

    • 子用户-1

例如,Sub用户是sub user-1的超级用户.这样,子用户将处理其超级用户的所有作业.

如何为此设计数据库.

几周前我参加了一个.NET开发小组会议,演讲者正在颂扬NoSQL的优点,如果只是索引大量数据,关系数据也不必相关地存储.所以,我的问题是:他抽烟了吗？如何制定一个指数比上一个更有效？索引是否只是逻辑地将信息以逻辑格式存储在表中,即按字母顺序存储？

考虑一个基本的表模式:

学生ID,学生姓名,部门,课程代码,课程名称,年级学期,年级

如何通过识别功能依赖关系将其转换为第二范式？