Questions tagged «database-design»

有关在数据库中构造数据的问题。如何布置表格，是否使用关系数据库，等等。

9
在代码中引用静态数据库数据的最佳方法？
许多应用程序都包含“静态数据”：这些数据在应用程序的生命周期中实际上并没有改变。例如，您可能有一个“销售区域”列表，该列表可能是在可预见的将来的固定列表。 在数据库表中找到此静态数据并不罕见（通常是因为您想在其他表的外键中引用它）。一个简单的示例表将具有一个ID（用作主键）和一个Description（描述）。例如，您的SalesArea表将具有（至少）一个SalesAreaId列和一个SalesAreaDescription列。 现在，在代码中，您可能不想将表的每一行都一样。例如，您可能想要在某些屏幕上设置默认的“销售区域”，为某些区域提供不同的数字，或限制用户在其他区域中可以执行的操作。 在代码中引用此静态数据的最佳方法是什么？为什么？ 在代码中硬编码描述。需要时，使用它可以从数据库中查找SalesAreaId。 将ID硬编码在您的代码中。在需要时使用它来查找SalesAreaDescription。 为每种目的在表中添加一列，例如“ IsDefaultOnProductLaunchScreen”列，依此类推（可能有很多）。 还有别的 处理静态数据库数据时，我还应该考虑其他一些特殊因素吗？例如，给这些表起一个特殊的名字？
2
多租户DB是否具有多个数据库或共享表？
是一个多租户数据库： 一个DB服务器对每个客户/租户有不同的（相同的）数据库/架构？要么 具有数据库/架构的DB服务器，客户/租户在其中共享同一表内的记录？ 例如，在上面的选项1下，我可能在处有一个MySQL服务器mydb01.example.com，并且其中可能有一个customer1数据库。该customer1数据库可能有10个表，这些表可以为该特定客户（客户1）提供我的应用程序。它也可能有一个customer2数据库，其中有完全相同的10个表，但是只包含Customer＃2的数据。它可能有一个customer3数据库，一个customer4数据库等等。 在上面的选项2中，将只有一个数据库/架构，例如myapp_db，又有10个表（与上面的表相同）。但是在这里，所有客户的数据都存在于这10个表中，因此他们“共享”了这些表。在应用程序层，逻辑和安全性控制着哪些客户可以访问这10个表中的哪些记录，并格外小心以确保客户＃1永远不会登录到应用程序并看到客户＃3的数据，等等。 这些范例中的哪一个构成了传统的“多租户” DB？如果两者都不是，那么有人可以提供一个多租户数据库示例吗（使用上述场景）？
8
为什么通常认为使用字符串键是一个坏主意？
这一直困扰着我一段时间。大多数时候，在将数据存储在诸如哈希表之类的结构中时，程序员，书籍和文章都坚持认为用String值对所述结构中的元素进行索引是不正确的做法。然而，到目前为止，我还没有找到一个单一的资料来源来解释为什么这被认为是不好的作法。是否取决于编程语言？在底层框架上？在执行上？ 举两个简单的例子，如果有帮助的话： 类似于SQL的表，其中的行由String主键索引。 .NET字典，其中的键是字符串。
3
分散数据管理-将数据库封装到微服务中
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我最近参加了一门软件设计课程，并且最近对使用“微服务”模型进行了讨论/推荐，在该模型中，服务的各个组成部分被分成了尽可能独立的微服务子组件。 提到的一部分是，不是遵循一种常见的模型，即所有微服务都与之通信的单个数据库，而是为每个微服务运行一个单独的数据库。 可以在此处找到措辞更好且更详细的解释：http : //martinfowler.com/articles/microservices.html在“分散数据管理”部分下 最突出的部分是这样说的： 微服务更喜欢让每个服务管理自己的数据库，或者是相同数据库技术的不同实例，或者是完全不同的数据库系统-一种称为Polyglot Persistence的方法。您可以在整体中使用多语种持久性，但是在微服务中它的出现频率更高。 图4 我喜欢这个概念，除其他外，我认为这是对维护的一项重大改进，并且有多个人在其中进行项目。也就是说，我绝不是经验丰富的软件架构师。有没有人尝试实现它？您遇到了哪些好处和障碍？
4
为什么许多设计会忽略RDBMS中的规范化？
想要改善这篇文章吗？提供此问题的详细答案，包括引文和答案正确的解释。答案不够详细的答案可能会被编辑或删除。 我看到很多设计都认为标准化不是决策阶段的首要考虑。 在许多情况下，这些设计包括超过30列，主要方法是“将所有内容放置在同一位置” 根据我记得，归一化是最重要的第一件事，那么为什么有时它这么容易掉下来？ 编辑： 好的建筑师和专家选择非规范化的设计，而没有经验的开发人员选择相反的设计，这是真的吗？反对着手规范化设计的观点是什么？
11
在数据库中为某些表创建辅助主键
我想在我的某些表中添加“ second_primary_key”，这将是uuid或一些随机的长键。我需要它，因为对于某些表，我不想向我的Web应用程序公开整数。也就是说，在页面“ / invoices”上，我有一个发票列表和一个指向“ / invoices /：id”的链接，其中：id是整数。我不想让用户知道我的系统中有多少张发票，因此我想使用其“ second_primary_key”代替“ / invoices / 123”，从而使URL为“ / invoices / N_8Zk241vNa” 我要隐藏真实ID的其他表也是如此。 我想知道，这是常见的做法吗？实现此目的的最佳方法是什么？ 到底该技术叫什么，以便我对此进行搜索？
3
如何在关系数据库中存储订购的信息
我正在尝试了解如何在关系数据库中正确存储有序信息。 一个例子： 假设我有一个由歌曲组成的播放列表。在我的关系数据库中，我有一个的表Playlists，其中包含一些元数据（名称，创建者等）。我还有一个名为的表Songs，其中包含playlist_id和特定于歌曲的信息（名称，艺术家，时长等）。 默认情况下，将新歌曲添加到播放列表时，它将添加到末尾。按Song-ID（升序）订购时，该顺序将为添加顺序。但是，如果用户应该能够对播放列表中的歌曲重新排序，该怎么办？ 我提出了一些想法，每个想法都有其优点和缺点： 称为的列order，它是整数。移动歌曲时，所有歌曲在其旧位置和新位置之间的顺序都会更改，以反映更改。这样做的缺点是，每次移动歌曲时都需要进行很多查询，并且移动算法不像其他选项那样琐碎。 称为的列order，它是一个十进制（NUMERIC）。移动歌曲时，会为其分配两个相邻数字之间的浮点值。缺点：十进制字段会占用更多空间，并且可能会精度不够，除非在每次更改后都注意重新分配范围。 另一种方法是使用previous和next字段引用其他歌曲。（或者，如果现在是播放列表中的第一首和最后一首歌曲，则为NULL；基本上，您将创建一个链表）。缺点：诸如“在列表中找到第X首歌曲”之类的查询不再是固定时间，而是线性时间。 在实践中最常使用以下哪个程序？在大中型数据库上，以下哪个过程最快？还有其他方法可以存档吗？ 编辑：为简单起见，在此示例中，一首歌曲仅属于一个播放列表（多对一关系）。当然，也可以使用Junction Table，因此song⟷playlist是一个多对多关系（并在该表上应用上述策略之一）。
9
关系数据库中的约束-为什么不完全删除它们？
如今，是否有任何理由在表之间（在SQLserver内部）建立约束？如果是这样，什么时候？我所在领域的大多数应用程序都是基于对象原理构建的，并且可以按需将表连接在一起。需求基于应用程序的需求。我不会加载一堆受约束的表来进行简单的查找，而这些查找又又（在执行操作之后）需要进行另一个简单的查找。 诸如EntityContext，Linq2Data，NHibernate之类的ORM工具也可以自己处理约束，至少您知道哪些表需要彼此使用。在服务器内部进行约束仅是对相同的更改进行两次（强制执行）？ 通常这不是要决定的问题，但是此数据库的设计却大不相同。设计看起来很正常，主要是镜像应用程序使用的对象。令我困扰的是在SQLserver内部使用“非级联”配置的所有约束。这意味着在编码新的数据库查询时，您必须扮演“寻找并查找”的角色。在某些情况下，单个订单最多需要10个级别的确切订单。 这让我感到惊讶，我不确定如何处理。 在我的简单世界中，这种设置使约束失去了大部分目的。如果在不了解设计的情况下从主机访问数据库，则单击“确定”。 在这种情况下，您将如何行动？ 为什么不从db中删除所有约束并将它们保持在应用程序级别呢？
5
多租户-单数据库与多数据库
我们有许多客户，他们的系统共享一些功能，但也有一定程度的多样性。客户数量在增长-永远是健康的事情！-他们的业务之间的差异也在增加。 当前，只有一个ASP.Net（Web窗体）网站（与Web项目相对），其中每个租户都有子文件夹，并带有该租户的非标准页面。有一个单独的模型项目，处理数据库访问和业务逻辑。 在（a）每个客户端拥有1个数据库且仅具有与该客户端相关联的功能之间，这是更好的选择，也是最重要的原因。（b）由所有客户端共享的单个数据库，其中任何一个客户端仅使用表的子集。 企业内部的主要担忧已经结束： 维护多个资产-备份，版本控制等 尽可能促进重复使用 您将如何确保解决这些问题，哪种解决方案更可取，为什么？（我也一直在整理类似问题的答案）
4
我应该在布尔型数据库字段中将False作为Null存储吗？
假设您有一个应用程序，该应用程序的表中有一个布尔字段，User称为Inactive。 仅将false存储为null是否有天生的错误？如果可以，请您解释一下不利之处吗？几个月前，我已经与某人讨论了这一点，我们都同意，只要您在整个应用程序/数据库中始终如一地进行操作，就没有关系。最近，我认识的某个人强调应该使用“ true” true或“ true” false，但是他们并没有真正解释原因。
8
处理已删除的用户-单独还是相同的表？
场景是我的用户数量在不断扩大，随着时间的流逝，用户将取消他们的帐户，这些帐户目前在同一表中被我们标记为“已删除”（带有标记）。 如果具有相同电子邮件地址的用户（这就是用户登录的方式）希望创建一个新帐户，则可以再次注册，但是会创建一个新帐户。（我们为每个帐户提供唯一的ID，因此可以在实时和已删除的电子邮件地址之间复制电子邮件地址）。 我注意到的是，在整个系统中，正常情况下，我们会不断查询user表，以检查用户是否被删除，而我在想的是，我们根本不需要这样做。 ！[澄清1：通过'不断查询'，我的意思是我们有这样的查询：'... FROM users WHERE isdeleted =“ 0” AND ...'。例如，我们可能需要提取特定日期所有会议的所有注册用户，因此在该查询中，我们还具有FROM用户WHERE isdeleted =“ 0”-这使我的观点更清楚了吗？] (1) continue keeping deleted users in the 'main' users table (2) keep deleted users in a separate table (mostly required for historical book-keeping) 两种方法的优缺点是什么？
5
为什么选择RIGHT JOIN而不是LEFT JOIN
如果我理解正确，每个RIGHT JOIN： SELECT Persons.*, Orders.* FROM Orders RIGHT JOIN Persons ON Orders.PersonID = Persons.ID 可以表示为LEFT JOIN： SELECT Persons.*, Orders.* FROM Persons LEFT JOIN Orders ON Persons.ID = Orders.PersonID 我个人认为该声明的意图是： 首先得到 Persons 然后Persons根据需要展开/重复，以匹配Orders 最好用的顺序来表示，而Persons LEFT JOIN Orders不是用相反的顺序来表示Orders RIGHT JOIN Persons（因此我从不使用RIGHT JOIN）。 有什么情况下RIGHT JOIN首选a？或者，是否有任何用例RIGHT JOIN可以做一些不能做的事情LEFT JOIN？
8
您将如何设计具有自定义字段的用户数据库
这个问题是关于我应该如何设计一个数据库，它可以是关系型/ nosql数据库，这取决于什么是更好的解决方案 根据要求，您需要创建一个系统，该系统将包含一个跟踪“公司”和“用户”的数据库。一个用户总是只属于一个公司 用户只能属于一个公司 一个公司可以有很多用户 “公司”表的设计非常简单。公司将具有以下属性/列：（让我们保持简单） ID, COMPANY_NAME, CREATED_ON 第一种情况 简单明了，用户都具有相同的属性，因此可以通过关系样式，用户表轻松完成此操作： ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON 第二种情况 如果不同的公司想要为其用户存储不同的配置文件属性，会发生什么情况。每个公司将具有一组定义的属性，这些属性将应用于该公司的所有用户。 例如： 公司A要存储：LIKE_MOVIE（布尔值），LIKE_MUSIC（布尔值） 公司B要存储：FAV_CUISINE（字符串） 公司C要存储：OWN_DOG（布尔值），DOG_COUNT（整数） 方法1 暴力方式是为用户提供一个单一的架构，并在不属于公司的情况下让其为空： ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, LIKE_MOVIE, LIKE_MUSIC, FAV_CUISINE, OWN_DOG, DOG_COUNT, CREATED_ON 这有点麻烦，因为您最终会得到很多NULL，并且用户行的列与它们不相关（即，属于公司A的所有用户的FAV_CUISINE，OWN_DOG，DOG_COUNT的值为NULL） 方法2 第二种方法是拥有“自由格式字段”： ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_1, CUSTOM_2, CUSTOM_3, CREATED_ON 由于您不知道什么是自定义字段，因此这本身就很麻烦，数据类型将无法反映所存储的值（例如，我们将int值存储为VARCHAR）。 方法3 …
5
数据库表何时应使用时间戳记？
首先要注意的是，我认为这个问题可能属于数据库交换，但我认为它总体上与编程解决方案有关，而不是与数据库有关。如果人们认为那是最好的，它将转向数据库交换。 我想知道何时在数据库表中添加创建和更新的时间戳？ 第一个明显的答案是，如果任何业务逻辑需要知道什么时候进行了更新（例如事务完成日期等），则必须将其输入。 但是非业务逻辑案例呢？例如，我可以想到这样的场景：了解行更改的日期时间以帮助进行故障查找是非常有用的，例如某些业务逻辑发生故障并查看相关的数据库行，从而有可能在更新之前确定一行正在更新导致错误的另一行。 在这种用例下，给每个表一个更新并创建时间戳是有意义的（也许最琐碎的枚举表可能不会被应用程序的任何部分更新）。 为每个表提供时间戳肯定是快速停顿数据库的好方法（尽管可能是错误的）。 那么什么时候数据库表应该使用创建和更新时间戳？
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.