Questions tagged «database-design»

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

12
将大文件（10 MB）存储在数据库中是不好的做法吗？
我当前正在创建一个Web应用程序，允许用户存储和共享1 MB-10 MB的文件。 在我看来，将文件存储在数据库中将大大降低数据库访问速度。 这是一个有效的问题吗？将文件存储在文件系统中并将文件名和路径保存在数据库中是否更好？使用数据库时，是否有与存储文件有关的最佳实践？ 我正在该项目的PHP和MySQL中工作，但是对于大多数环境（Ruby on Rails，PHP，.NET）和数据库（MySQL，PostgreSQL）都是相同的问题。
9
在关系数据库中使用列表可以吗？
我一直在尝试设计一个与项目概念相适应的数据库，并遇到了一个似乎引起激烈争论的问题。我已经阅读了几篇文章和一些Stack Overflow的答案，指出永远（或几乎永远）无法在字段中存储ID或类似内容的列表-所有数据都应该是相关的，等等。 不过，我遇到的问题是我正在尝试创建任务分配器。人们将创建任务，将其分配给多个人，并将其保存到数据库中。 当然，如果我将这些任务分别保存在“人员”中，则必须有几十个虚拟的“任务ID”列并对其进行微管理，因为可以将0到100个任务分配给一个人。 再一次，如果我将任务保存在“任务”表中，则必须有几十个虚拟的“ PersonID”列并对其进行微管理-与以前一样的问题。 对于这样的问题，是否可以保存采用一种形式或另一种形式的ID列表，或者我只是不考虑另一种可以在不违反原则的情况下实现的方式？
7
代码优先与数据库优先
在设计和创建要使用的软件时，通常会先设计和创建后端SQL表，然后再进行实际编程。我目前正在从事的项目让我感到困惑。这可能是由于缺乏良好而可靠的要求所致，但是不幸的是，这次我对此几乎无能为力。这是一种“随它去吧”的情况，但是我离题了。 我正在考虑将工作流程从头开始，并首先创建UI和数据模型类，以期解决该问题将使我清楚我的数据库架构最终将是什么样。这是一个好主意吗？我很担心自己最终将获得一个UI，但仍然不知道如何构造数据库。 如果有人好奇，我将SQL Server用作后端，将MS Access用作前端应用程序。（访问也不是我的选择...所以请不要对此感到讨厌。）
6
EAV-在所有情况下真的不好吗？
我正在考虑对其中一个项目中的某些内容使用实体属性值（EAV）模型，但是在Stack Overflow中有关它的所有问题最终都会导致将EAV称为反模式。 但是我想知道在所有情况下这是否是错误的。 假设商店产品实体具有共同的特征，例如名称，描述，图像和价格，它们在许多地方都参与了逻辑，并且具有（半）独特的特征，例如手表和沙滩球将通过完全不同的方面进行描述。因此，我认为EAV将适合存储那些（半）独特的功能。 所有这些假设是，为了显示产品列表，产品表中有足够的信息（这意味着不涉及EAV），并且仅在显示一个产品/比较最多5个产品/等时。使用通过EAV保存的数据。 我已经在Magento商业中看到了这种方法，并且这种方法非常流行，那么是否存在EAV合理的情况？
7
配置数据：单行表与名称-值对表
假设您编写了一个可由用户配置的应用程序。为了将该“配置数据”存储到数据库中，通常使用两种模式。 该单行表 CompanyName | StartFullScreen | RefreshSeconds | ... ---------------+-------------------+------------------+-------- ACME Inc. | true | 20 | ... 的名称-值对表 ConfigOption | Value -----------------+------------- CompanyName | ACME Inc. StartFullScreen | true (or 1, or Y, ...) RefreshSeconds | 20 ... | ... 我已经看到了两种选择，它们都有明显的优缺点，例如： 单行表限制了您可以拥有的配置选项的数量（因为通常限制一行中的列数）。每个其他配置选项都需要更改数据库架构。 在名称/值对表中，所有内容都是“字符串类型的”（您必须对Boolean / Date / etc。参数进行编码/解码）。 （还有很多） 开发社区内部对于哪种选择更可取达成共识？
10
添加数据库索引是否过早优化？
今天，我的一位同事建议我们仔细检查应用程序中的所有查询并相应地添加索引。 我觉得这是过早的优化，因为我们的应用程序尚未发布。我建议我们上线后监视慢速查询，然后相应地添加索引。 在设计数据库时，一般的共识是什么？每次编写新查询时都应添加匹配的索引吗？还是只监视并查看进展情况更好？
4
为什么将MySQL用于字典网站是个坏主意？
我打算设计和建立一个数据库，以存储词典条目（通常是单个单词）及其在另一种语言中的含义。因此，例如，表Glossary必须具有条目和定义，并且每个表记录都具有对存储在其中的记录的ID的引用Tag（每个条目必须具有标签或类别）。 由于我的数据具有结构，因此我认为使用SQL数据库（如MySQL）并不是一个坏主意；但是人们说MongoDB的性能要好得多。 在客户端，应用程序必须能够提供一个具有自动完成功能的搜索框，该框使用后端提供的REST API。在这种情况下使用MySQL是否安全？还是应该为此使用MongoDB或任何其他解决方案的ElasticSearch？应该以这种方式存储和访问数十万条记录。
8
在数据库中存储可重新排序的列表
我正在开发一个愿望清单系统，该系统中用户可以将商品添加到他们的各种愿望清单中，并且我打算允许用户稍后重新订购这些商品。我不确定如何将其存储在数据库中同时保持快速且不会陷入混乱的最佳方法（此应用程序将由相当大的用户群使用，所以我不希望它崩溃清理东西）。 我最初尝试了一个position列，但是当您移动其他每个项目的位置值时，似乎效率很低。 我见过人们使用自引用来引用上一个（或下一个）值，但是同样，您似乎必须更新列表中的许多其他项。 我见过的另一种解决方案是使用十进制数字，并且仅将项目粘贴在它们之间的间隙中，这似乎是迄今为止最好的解决方案，但我敢肯定必须有更好的方法。 我要说的是，一个典型的列表最多可以包含20个左右的项目，并且我可能会将其限制为50个。重新排序将使用拖放操作，并且可能会分批进行以防止出现竞争情况，例如ajax请求。如果有关系，我正在使用postgres（在heroku上）。 有人有什么想法吗？ 为任何帮助加油！
13
是否需要创建一个尽可能少的表的数据库
我们是否应该创建具有最少表数的数据库结构？ 应该以一种将所有内容都放在一个地方的方式进行设计，还是可以有更多的桌子？ 反正会影响什么吗？ 我问这个问题是因为我的一个朋友修改了mediaWiki中的某些数据库结构。最后，他只用了8张桌子而不是20张桌子，花了8个月的时间才完成（这是他的大学任务）。 编辑 我得出的结论是：在特殊情况下，表的大小并不重要；在这种情况下，非规范化可能会有所帮助。 感谢大家的答案。
8
对于需要按内容搜索的大型数据集，使用NoSQL数据库是否不切实际？
我已经学习NoSQL数据库已有一个星期了。 我真的了解NoSQL数据库的优势以及它们非常适合的许多用例。 但是人们通常会在撰写文章时就好像NoSQL可以代替关系数据库一样。还有一点我无法理解： NoSQL数据库是（通常）键值存储。 当然，可以将所有内容存储到键值存储中（通过将数据编码为JSON，XML等），但是我看到的问题是，在许多情况下，您需要获取一些与特定条件匹配的数据用例。在NoSQL数据库中，只有一个可以有效搜索的条件-密钥。关系数据库经过优化，可以有效地搜索数据行中的任何值。 因此，NoSQL数据库并不是持久存储需要按其内容搜索的数据的真正选择。还是我误会了什么？ 一个例子： 您需要存储网上商店的用户数据。 在关系数据库中，您将每个用户存储为users表中的一行，并带有ID，名称，他的国家等。 在NoSQL数据库中，您将以ID为密钥存储每个用户，并将其所有数据（以JSON等编码）存储为值。 因此，如果您需要从某个特定国家/地区获取所有用户（出于某种原因，营销人员需要了解他们的某些信息），那么在Relational Database中这样做很容易，但是在NoSQL Database中却不是很有效，因为您必须获取每个用户，解析所有数据并进行过滤。 我并不是说这是不可能的，但是它变得更加棘手，如果您要搜索NoSQL条目的数据，我想那不是那么有效。 您可以为每个国家/地区创建一个密钥，以存储该国家/地区中每个用户的密钥，并通过获取存放在该国家/地区的密钥中的所有密钥来获取特定国家/地区的用户。但是我认为这种技术使复杂的数据集变得更加复杂-难以实现且不如查询SQL数据库有效。因此，我认为这不是您在生产中使用的方式。还是？ 我不确定我是否会误解或忽略了一些概念或最佳实践来处理此类用例。也许您可以纠正我的陈述并回答我的问题。
7
我如何令人信服地反对复制数据库列？
我已经开始在一个新组织中工作，我在数据库中看到的一种模式是复制字段，以使业务分析师更容易编写查询。我们正在使用Django及其ORM。 在一种情况下，我们保留一个MedicalRecordNumber对象，该对象带有在特定上下文中标识患者的唯一字符串。我们有登记其追踪病人和有关联的对象MedicalRecordNumbers，但不是使用外键关系，他们复制的字符串，使他们能够避免写一个连接（不是由于性能原因）。这种模式在整个数据库中很常见。 对我来说，干净的数据模型的重要性只是为了让我能好好考虑一下。不必要的复杂性浪费了我有限的认知处理时间。这是一个系统的问题。编写连接不舒服是一个可纠正的技能问题。我不一定要提倡返回并更改模式，但我希望能够令人信服地阐明此类重复问题。
7
数据库约束发生了什么？
当我查看RDBMS的数据库模型时，通常会惊讶地发现几乎没有约束（除了PK / FK）。例如，百分比通常存储在类型的列中int（虽然tinyint会更合适），并且没有CHECK约束将值限制为0..100范围。同样在SE.SE上，建议检查约束的答案通常会收到注释，表明数据库是约束的错误位置。 当我询问不实施约束的决定时，团队成员会回答： 他们甚至都不知道自己喜欢的数据库中是否存在这样的功能。对于仅使用ORM的程序员而言，这是可以理解的，但是对于声称拥有给定RDBMS 5年以上经验的DBA而言，这是可以理解的。 或者它们在应用程序级别强制执行此类约束，并且在数据库中复制这些规则不是一个好主意，这违反了SSOT。 最近，我看到越来越多的项目甚至不使用外键。同样，我在SE.SE上看到了一些评论，这些评论表明用户不太在意引用完整性，让应用程序来处理它。 当询问团队有关不使用FK的选择时，他们说： 例如，当必须删除其他表中引用的元素时，它就是PITA。 NoSQL坚如磐石，那里没有外键。因此，我们在RDBMS中不需要它们。 就性能而言，这并不是什么大问题（上下文通常是在小型数据集上运行的小型Intranet Web应用程序，因此，实际上，即使索引也没有太大关系；没有人会介意给定查询的性能是否超过1.5 s到20毫秒）。 当我查看应用程序本身时，我系统地注意到了两种模式： 该应用程序会正确清理数据并在将其发送到数据库之前对其进行检查。例如，无法102通过应用程序将值存储为百分比。 该应用程序假定来自数据库的所有数据都是完全有效的。就是说，如果102以百分比来表示，某处某处将崩溃，或者仅将其按原样显示给用户，从而导致奇怪的情况。 尽管超过99％的查询是由单个应用程序完成的，但随着时间的流逝，脚本开始出现-要么在需要时手动运行脚本，要么执行cron作业。还可以手动对数据库本身执行某些数据操作。脚本和手动SQL查询都具有引入无效值的高风险。 这是我的问题： 没有关系约束而最终甚至没有外键的关系数据库建模的原因是什么？ 就其价值而言，这个问题和我收到的答案（尤其是与Thomas Kilian进行的有趣的讨论）使我写了一篇有关数据库约束的结论文章。
8
域驱动设计是一种反SQL模式吗？
我正在研究域驱动设计（DDD），尽管我对此进行了更深入的了解，但有些事情我还是没有。据我了解，主要要点是将域逻辑（业务逻辑）与基础结构（数据库，文件系统等）分开。 我想知道的是，当我遇到非常复杂的查询（例如材料资源计算查询）时会发生什么？在这种查询中，您需要使用繁重的集合操作，这是SQL设计的目的。在域层内部进行这些计算并使用其中的许多集合就像丢弃SQL技术一样。 在基础架构中也无法进行这些计算，因为DDD模式允许在基础架构中进行更改而无需更改域层，并且知道MongoDB不具有SQL Server等相同的功能，这是不可能发生的。 这是DDD模式的陷阱吗？
5
当您无法确定布尔值时该怎么办？
我们正在为公司构建一个Web应用程序，到目前为止，该管理仅存在于Excel工作表中。到现在我们已经差不多完成了，但是最近我被分配了一个任务，将所有数据从这些工作表导入到我们的新系统中。该系统是用Java构建的，但是由于这种导入只是一次性的事情，因此我决定改用Python编写脚本，然后直接通过SQL查询将其导入。问题来了。新数据模型包含一些新属性，这些新属性未包含在其现有数据中。在大多数情况下，这不是问题，我在找不到信息的地方放了一个null。但是随后我遇到了一些属性，它们是布尔值，默认情况下不能为NULL。首先，我尝试只允许数据库中的这些字段为空，但是我的资深开发人员告诉我不要这样做，因为这将来会在我们的系统中引起问题。现在我不太确定该怎么做。显而易见的解决方案是将每个未知布尔值默认设置为false，但是我认为这也是错误的，因为我实际上不知道它是否为false。 示例：假设您有一个具有hasRadio参数的实体Car。现在，您需要将数据导入此数据模型，但是在数据中只有“模型”和“颜色”列，关于是否具有无线电没有任何内容。如果设计上不能将其设置为空，那么您将在“ hasRadio”列中添加什么？ 在这种情况下最好的方法是什么？我们是否应该告诉公司手动填写丢失的数据？还是默认为false？
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.