Questions tagged «database-design»

数据库的概念模式和/或逻辑模型和/或物理设置的开发。

3
两个可为空的列，其中一个必须具有值
不解释问题： 无论如何，是否有2个空值的约束总是需要1个有值？例如，两个日期列都为空，但至少有 1个需要具有一个值 问题描述： 假设我有一个名为Expense的表格 并有两个日期： prevision_expense_expiration_date DATE为空ABLEABLE_payment_date DATE为空 这两列的逻辑如下： 我买了东西，我知道我得为此花些钱，例如电话费。我将其作为费用输入，并带有expense_payment_date。该日期是我应该支付的假定日期，而不是实际的支付日期，例如发票的到期日期。 在其他情况下，我会出售某些提供者提供的服务的礼品卡。我可能有买我的提供商的服务转移到我的客户的费用只有当客户赎回卡。因此，礼品卡有一个有效期，我想对该“费用”做一个预先准备，而不插入礼品卡有效期内的费用，如果礼品卡过期，则“费用”不应输入到帐户中系统。 我知道我可以有2个相等的表，分别称为prevision_expense和Confirmed_expense，但是听起来不对，所以我在同一张表中有2个日期，可以为空，但是我想约束一下，以便始终需要一个。 还有另一种可行的策略： payment_date DATE NOT NULL is_prevision_date BOOL NOT NULL 因此，在这种情况下，如果日期为prevision，则bool值将为1，否则将为0。没有空值，一切都很好。除了我希望可以选择在第一次有预先设定日期时存储两个值，然后（然后说两天后说）确定该费用的日期时，在这种情况下，采用策略2时，我将没有该选项。 我在数据库设计中做错了什么吗？：D
3
将公式存储在表中并在函数中使用该公式
我有一个PostgreSQL 9.1数据库，其中部分处理代理佣金。每个代理商都有自己的计算公式，他们可以得到多少佣金。我有一个函数来生成每个代理应获得的佣金数量，但是随着代理数量的增加，它变得无法使用。被迫做一些非常长的case语句和重复代码，这使我的功能变得非常庞大。 所有公式都有常量变量： d ..该月工作的天数 r ..新节点累积 l ..忠诚度得分 s ..子代理人佣金 b ..基本利率 我..获得的收入 公式可以是： d*b+(l*4+r)+(i/d)+s 每个代理商与人力资源部门协商付款方式。因此，我可以将公式存储在代理表中，然后像一个小的函数一样，仅从表中获取公式并将其转换为值并计算金额吗？
4
如何处理大型未记录数据库
最近，我被某公司X聘为唯一的IT专家，我的任务是修复他们的应用程序，我认为，最好的开始方法是了解数据库。 他们当前的数据库是带有186个表的MySQL数据库（请注意，有些表是空的，上帝知道原因）。应用程序正在通过MS Access数据库接口与数据库进行通信。（我问自己为什么开发商也这样做） 问题是，如何开始处理这个大型的未公开文档的数据库？是的，它没有记录，因为应用程序的开发人员不愿意给我ERD或数据字典或有关数据库的任何信息来简化我的生活。您如何建议您进行这项艰巨的工作，即了解相当大的数据库的每个细节？ 相关问题：如何进入一个丑陋的数据库？
1
修改（减少）列的长度时会发生什么？
可以说我有两列类型NUMBER（无精度和小数位数）和VARCHAR(300)。我看到这些列对于我的数据来说太大了，所以我想将它们修改为NUMBER(11)和VARCHAR(10)。因此，如果我运行此SQL语句： ALTER TABLE FOO MODIFY(BAR NUMBER(10)); 我可以在非空列上执行此操作吗？ 如果是这样，那么如果有一个大于的值NUMBER(10)，oracle会告诉我吗？ 如果先前定义，列默认值是否会保持不变？ 列为空的选项会保持不变吗？ 该列上的主键，外键，唯一键是否保持不变？ 涉及该列的约束条件将保持不变吗？ 该列上的索引会保持不变吗？ 是否有任何官方文件回答我的问题？
3
库存项目具有不同属性时的库存数据库结构
我正在建立一个库存数据库来存储企业硬件信息。数据库跟踪的设备范围从工作站，便携式计算机，交换机，路由器，移动电话等开始。我使用设备序列号作为主键。我遇到的问题是这些设备的其他属性各不相同，并且我不希望清单表中的字段与其他设备无关。下面是数据库部分ERD的链接（未显示某些FK关系）。例如，我正在尝试进行设置，因此无法将具有工作站设备类型的设备放入手机表中。这似乎需要使用许多触发器来验证设备类型或类，并且只要有不同属性的不同设备被跟踪，就可以创建新表。 我研究了设置可以映射到序列号的属性表，但是这将允许将不适用于设备类型的属性分配给设备，例如，有人可以根据需要将电话号码属性分配给工作站。我在此站点上找到了一个解释，该解释给出了以下结构： 如果属性都适用于我要存储的项目，则此结构将非常有用。例如，如果数据库仅存储手机，则属性可以是诸如触摸屏，触控板，键盘，4G，3G ...之类的东西。在这种情况下，它们都适用于电话。我的数据库将具有诸如主机名，circuitType，phoneNumber之类的属性，这些属性仅适用于特定类型的设备。 我要进行设置，以便仅将适用于给定设备类型的属性分配给该类型的设备。关于如何设置此数据库的任何建议？我不确定这是否是一对一关系的正确使用，还是有更好的方法来做到这一点。预先感谢您抽出宝贵的时间对此进行研究。 这是我阅读的其他一些主题。他们给了我一些很好的见解，但我认为它们并不适用： /programming/9335548/how-to-structure-database-for-inventory-of-unlike-items /programming/1249632/database-structure-for-items-with-varying-attributes /programming/5559587/product-inventory-with-multiple-attributes /programming/6613802/question-about-setting-up-inventory-database /programming/514111/how-to-best-represent-items-with-variable-of-attributes-in-a-database
5
ER图的重要性
我是一名学生，并且正在作为学术界的一部分开发多个项目。 在为其中一个项目开发数据库时，我们遇到了一种情况，即我们在考虑是否需要ERD。目前，并不是我们每个人都同意先开发ERD，然后再从中开发数据库。 大多数人都喜欢直接根据书面要求在系统上实时地开发数据库。 现在，我是数据库原则的严格追随者。我认为该数据库应仅从ERD开发。因此，我只想了解以下内容： 业界是否遵循这些原则？ 我只是在浪费时间开发ERD吗？ 开发ERD有什么好处？
4
使用广泛的PK与单独的合成密钥和UQ之间的性能考虑因素是什么？
我有几个表，其中的记录可以通过几个广泛的业务领域进行唯一标识。过去，我将这些字段用作PK，并牢记以下好处： 简单; 没有多余的字段，只有一个索引 群集允许快速合并联接和基于范围的过滤器 但是，我听说过创建合成IDENTITY INTPK，而用单独的UNIQUE约束来强制业务密钥的情况。优点是，较窄的PK使得二级索引要小得多。 如果一个表有没有比PK其他指标，我看不出有任何理由赞成第二种方法，虽然在一个大表它可能是最好的假设，指数可能在未来是必要的，因此，有利于在狭窄合成PK 。我有什么需要考虑的地方吗？ 顺便说一句，我并不是在反对在数据仓库中使用合成密钥，我只是对何时使用单个广泛的PK，何时使用狭窄的PK加广泛的英国感兴趣。
2
我可以无损地分解这张桌子吗？
我偶然发现了一个数据库设计问题，而这个数据库设计问题超出了我的能力范围，而我的DBA专家也开始进行防火训练。 本质上，我有一个带有以下主键的表（为简洁起见，PK）： child_id integer parent_id integer date datetime child_id并且parent_id是实体表的外键。“子”表本身还包含“父”表的外键，并且lo child_id始终引用与parent_id上表所期望的相同的外键。实际上，事实证明，还有一些额外的代码可以使两者保持同步。 这使这位热情洋溢的标准化新手说：“我应该删除冗余！” 我分解为以下内容： Table_1 PK: child_id integer date datetime Table_2 PK: parent_id integer date datetime Table_3: (already exists) child_id integer PRIMARY KEY parent_id integer FOREIGN KEY 而且，当我自然地将这些人加入一起时，我将恢复原始表。据我了解，制造出了5NF。 但是，现在我意识到存在隐藏的业务规则。 通常，与给定日期关联的日期child_id必须是与对应日期关联的日期的子集parent_id。您可以看到第一个表强制执行此规则。 我的分解不会强制执行该规则，因为您可以自由地将其添加到表1中，直到日期变得太大为止。 这将我引向以下问题： 这是5NF分解吗？虽然我说它允许插入异常，但它似乎也遵循Wiki示例，该示例本身遵循本指南。短语（强调我）“我们可以从由三种不同的记录类型组成的规范化形式中重构所有真实事实”，这给了我一个特殊的停顿，因为无论我注入多少垃圾Table_1，自然连接仍然会忽略它。 假设我不喜欢这种分解（我不喜欢）。我自由地承认，实际的解决方案是保留表和代码不变。但是，从理论上讲，是否有一种方法可以分解和/或添加约束，以使我摆脱第一个表并保留我的业务规则？
4
在时间维度表中应该将索引放在哪里？
在阅读了该网站有关索引的问答后，我想到了一个问题。 如果使用的是时间维度表，而粒度级别较低则为日。索引应该放在哪里？ Randy Melder的问题是：“索引”在RDBMS上意味着什么？说过 ： 将索引视为“目录” ...即文件位置的指针的有序列表，又称偏移量 就时间维度而言，如果时间表存储了唯一年份的全天，则大多数数据研究可能针对特定的一天，特定的一周，特定的月份或特定的季度进行。 我的问题是：是否应该为所有这些字段设置索引？ Day被认为是唯一的，因此对于这一天，我完全理解索引的使用。但是一个星期id将发生7次，一个月id将发生30/31次，一个季度id将或多或少发生120次。 还应该为那些字段添加索引吗？ 还会有用吗？ 我问你，因为在同一问题上，大卫·斯皮利特（David Spillett）说： 当然，添加过多的索引可能是一个糟糕的优化，因为用于存储索引的额外空间（如果您的DB看到许多写操作，则还有用于维护索引的IO负载）可能比最优读取请求稍差一些，这是一个更糟糕的问题。 ，所以不要过度操作。 那么，对于时间维度情况，最好的考虑因素是什么？
2
标志与表拆分
我正在设计一个项目表，该项目表（可能）包含数千万条记录。某些项目只有在管理员“批准”之后才能使用。“使用”是指在“批准”之前不会在其他任何表中引用这些项目。在任何给定时间，多达50％的商品可能会被“未批准”。记录可能会被“批准”，但反之则不然。 我考虑两个设计选项： 一点标志 单独的“未批准”项目表-批准项目后，将其移至“常规”表（项目ID的更新不是问题） 我认为第二个选择要好得多。位标志每行仅占用一个字节，因此这不是问题。但是，如果我们在同一张表中有100万个批准的记录和100万个未批准的记录，则具有批准记录的操作的扫描时间会增加。 问题是：我应该考虑使用第一个（位标志）选项吗？在描述的情况下有什么好处吗？
2
喜欢或投票推荐
我正在制作一个小程序，用户可以在其中编写帖子或撰写博客。在这些帖子上，其他用户可以像在Facebook中那样喜欢或不喜欢该帖子，或者像在stackoverflow中那样对帖子进行赞或不赞成。我想知道一个常用的良好数据库结构，并且该程序可以有效地使用该结构。我有两个选择 第一 发布： id head message datepost likes dislikes 1 ab anchdg DATE 1,2,3 7,55,44,3 以上述方式，id是postid。在“喜欢”列中，1,2,3是喜欢或赞成该帖子或博客的用户的ID。7,55,44,3是不喜欢或不赞成该帖子或博客的用户的ID。 第二 发布： id head message datepost 1 ab anchdg DATE 喜欢： id postid userid 1 1 1 2 2 2 不喜欢： id postid userid 1 1 7 2 1 55 这样，我必须为喜欢和不喜欢创建两个单独的表，以获取帖子的喜欢。这样，表即Likes＆Dislikes将被大量填充。这可能会使表沉重，处理速度变慢。 因此，我想知道哪种更好和更标准的方法来完成此任务？
1
加强约束“两张桌子”
我在用SQL建模电气原理图时遇到了一些麻烦。我想捕捉的结构是 part ←────────── pin ↑ ↑ part_inst ←───── pin_inst 其中“实例”是“实例”的缩写。 例如，作为partLM358运算放大器，我可能具有pins 1OUT，1IN-，1IN +，GND，2IN +，2IN-，2OUT和V CC。然后，我可能将此零件放在原理图上，并创建一个part_inst和8 pin_insts。 忽略数据字段，我最初对模式的尝试是 create table parts ( part_id bigserial primary key ); create table pins ( pin_id bigserial primary key, part_id bigint not null references parts ); create table part_insts ( part_inst_id bigserial primary key, part_id …
2
此“映射”表是否需要单独的Id列？
我有Producers和的表Products，两者的形式均为： Id -int，主键 Name -nvarchar 一个生产者可以携带多个产品，所以我要创建一个表ProducerDetails，该表将具有： ProducerId -int，外键 Producers.Id ProductId -int，外键 Products.Id 然后我开始质疑自己，所以我想问专家。Id在ProducerDetails表中增加一个附加列（int，主键）会更好吗？还是那是不必要的？ 如果这有任何区别，我正在使用SQL-Server 2008 R2。 编辑 -我相信这些表之间的关系将是多对多的，抱歉，我没有说清楚。一个生产者可以携带多种类型的产品，并且同一产品可以由多个不同的生产者生产。 如果这个问题过于简单，我很抱歉，参照完整性/数据库设计不是我的强项（尽管我正在努力改善这一点）。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.