Questions tagged «database-design»

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

3
创建新的数据库表而不使用枚举数据类型是否浪费资源?
假设我提供4种服务类型(它们不太可能经常更改): 测试中 设计 程式设计 其他 假设我有60-80个实际服务,每个服务都属于上述类别之一。例如,“服务”可以是“使用技术A的测试程序”,并且类型为“测试”。 我想将它们编码到数据库中。我想出了一些选择: 选项0: 使用VARCHAR直接直接编码的业务类型为字符串 选项1: 使用数据库enum。但是,枚举是邪恶的 选项2: 使用两个表: service_line_item (id, service_type_id INT, description VARCHAR); service_type (id, service_type VARCHAR); 我什至可以享受参照完整性: ALTER service_line_item ADD FOREIGN KEY (service_type_id) REFERENCES service_type (id); 听起来不错,是吗? 但是我仍然必须对事物进行编码并处理整数,即在填充表时。或者在填充或处理表时必须创建精心设计的程序或数据库结构。即,在直接处理数据库或在编程端创建新的面向对象的实体并确保我正确操作它们时,可以使用JOIN。 选项3: 不使用enum,不使用两个表,而只使用一个整数列 service_line_item ( id, service_type INT, -- use 0, 1, 2, 3 (for service …

3
自引用表,好还是坏?[关闭]
代表应用程序中的地理位置,基础数据模型的设计提出了两个明确的选择(或可能还有更多选择)。 一个表,带有一个自引用的parent_id列UK-伦敦(伦敦父母ID =英国ID) 或两个表,使用外键一对多关系。 我更喜欢一个自引用表,因为它可以轻松扩展到所需的子区域。 通常,人们会偏离自引用表,还是可以?

6
我应该为每个应用程序使用一个数据库还是在多个应用程序中共享一个数据库?
我有多个应用程序,其中一些使用来自相同来源的数据。最佳做法(或优点/缺点)是: 将数据保留在多个应用程序共享的数据库中 节省空间,因为只需要一个数据库 索引复杂化,因为不同的应用程序具有不同的查询需求 每天将数据导入每个应用程序数据库 每个应用程序数据库中存在重复数据,因此使用更多空间 索引更容易,因为每个应用程序都可以专注于其各自的需求 我可能遗漏了其他优点/缺点,请列出(如果有),在您的工作场所该如何做?

7
分别建模名字和姓氏
在设计新系统时,应该考虑哪些参数,并且必须将一个人的姓名存储为一个字段,或者将其分别存储为名字/姓氏? 单一领域的优点: 简单的用户界面 尝试输入一个名字很长的人的名字时没有歧义(通常不明显,这是姓氏/名字..) 处理标题时的复杂度较低(例如,无需单独输入“ MD”或“ Dr.”) 拆分字段的优点: 可以通过“亲爱的X先生”或“亲爱的朱莉”进行个性化交流 如果使用的Web服务需要单独的名字/姓氏,则可以轻松提供。 对于具有严格标识要求的任何行业(例如医疗,政府等)的更好选择 选择更加安全,因为您可以随时返回到单一字段替代方案 您是否看到上面未列出的任何其他参数? 更新:问题是,可以为每个解决方案列出哪些其他(未在问题中列出)参数。我认为提出意见而不是可能的利弊会以错误的方式推动讨论。每个开发人员都必须对这个问题做出决定,这个问题的目的是汇编一个非平凡的参数列表,可以在需要时进行评估。

5
没有中央数据库
我有一个客户正在寻求构建处理非常敏感的数据(比银行/卡详细信息更敏感)的网站/移动应用/桌面应用。由于数据的敏感性,他们不想将其保存在中央数据库中,但他们仍然希望其应用程序进行同步(假设我将一些数据添加到了移动应用程序中,然后我希望能够转到我的移动应用程序中。桌面应用程序并看到相同的数据)。 我想不出一种不错的,可靠的方法来做到这一点,我不确定是否有一种方法。这就是为什么我在这里。有谁知道我该如何处理这些数据? 我正在考虑的一种解决方案是在每个应用程序上都有一个客户端数据库,该数据库将以某种方式在应用程序之间进行同步,我可以看到这是非常不可靠的,而且变得混乱。

8
前端优先或后端优先。这两个是好的系统设计实践?
我现在有一个客户,要求我开发学校注册系统。现在,这是我第一次遇到这种挑战。我创建的大多数过去的软件都没有那么复杂。 我知道你们大多数人都已经创建了复杂的软件,我只想就此提出建议。我应该先设计前端还是后端? 谢谢! 这是我前一段时间在互联网上找到的一篇文章的结论。只想分享 http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157 前端与后端开发人员(我的看法) 我个人的看法 同样,这是一个培训问题,一些广泛的笔画概括: 前端开发人员 通常没有CS学位,或者没有三级学校的CS学位。 使用与基本语言类似的语言(请参阅PHP是基本语言) 具有将photoshop文档转换为CSS / HTML / etc的视觉技巧。 由于使用无类型语言,因此对迭代编程具有较高的容忍度 后端开发人员 有CS学位或丰富经验 在他们的问题解决方法上趋向于我 不要介意花几天时间寻找一个正在泄漏的物体 尝试构建工具来解决问题

1
什么时候应该使用文档数据库,关系数据库和图形数据库?[关闭]
为了讨论的目的,让我们考虑一个FourSquare方案。 情境 实体: 用户数 地方 关系: 签到:用户<->地点,很多对很多 朋友:用户<->用户,多对多 数据库设计 这些很可能有错误,请指出。 关系数据库管理系统 表格: 用户数 地方 签到(交界处) 朋友(交界处) 优点: CAP:一致性,可用性 缺点: CAP:分区容限,也称为分片 方案=不灵活的结构 复制不良? 图形 对象: 用户数 地方 边缘: 朋友:用户<->用户 签到:用户->地点 包含时间戳 优点: CAP:一致性,可用性? 无模式,易变的对象和边缘 图形遍历查询,例如: 聚类 寻找一群朋友 寻找类似人喜欢的餐厅 还有其他常见/有用的查询吗? 缺点: CAP:分区容忍度? 文件/物件 3个独立的数据库? 用户数 朋友清单 签到 时间戳记 用户 地点 地方 优点: …

2
为什么在数据库中将标记/枚举存储为字符串而不是整数?
我一直在浏览一些著名CMS的SQL转储,包括Drupal 7,Wordpress(一些非常旧的版本)以及一些基于Python的自定义应用程序。 所有这些转储都包含带有字符串标志而不是整数标志的数据。例如,一个职位的状态表示为published,closed或inherit不是1,2或3。 我在数据库设计方面的经验非常有限,并且从未尝试过使用简单的SQL,但是始终有人告诉我,应该对此类数据使用数字/整数标志。显然tinyint,与例如相比,在数据库中占用的空间要少得多varchar(9)。 那我想念什么呢?这不是浪费数据存储和数据冗余吗?如果这些列使用整数而不是字符串,浏览,搜索和索引编制会不会更快一些?

9
您如何组织高度定制的软件?
我正在从事一个大型软件项目,该项目针对世界各地的各种客户进行了高度定制。这意味着我们可能有80%的代码在各个客户之间是通用的,但是还有很多代码必须从一个客户转换到另一个客户。过去,我们是在单独的存储库(SVN)中进行开发的,而当一个新项目开始时(我们的客户很少,但客户众多),我们根据过去的项目中最能满足我们需求的代码创建了另一个存储库。过去一直有效,但是我们遇到了几个问题: 在一个存储库中修复的错误不会在其他存储库中修补。这可能是组织问题,但我发现很难在5个不同的存储库中修复和修补错误,请记住,维护该存储库的团队可能位于世界的另一部分,并且我们没有测试环境,既不知道他们的时间表,也不知道他们有什么要求(一个国家的“错误”可能是另一个国家的“功能”)。 为一个项目进行的功能和改进可能对另一项目也可能有用,或者丢失了这些功能或进行了改进,或者如果将这些功能和改进用在另一个项目中,则经常导致将它们从一个代码库合并到另一个代码库的麻烦(因为两个分支可能已经独立开发了一年) )。 如果必须在分支之间合并所有这些更改,则在一个开发分支中进行的重构和代码改进可能会丢失或造成的危害大于弊。 我们现在正在讨论如何解决这些问题,到目前为止,我们提出了以下解决方案: 将开发保持在单独的分支中,但是要通过建立一个中央存储库来更好地组织它,其中将常规错误修复程序合并到其中,并使所有项目定期(例如每天)将来自该中央存储库的更改合并到自己的更改中。这需要庞大的纪律和分支之间的合并工作。因此,我不相信这会奏效,并且我们可以保持这一纪律,尤其是在时间压力加大的情况下。 放弃单独的开发分支,并建立一个中央代码存储库,我们所有的代码都将存在于此,并通过具有可插拔模块和配置选项进行自定义。我们已经在使用Dependency Injection容器来解析代码中的依赖关系,并且我们在大多数代码中都遵循MVVM模式,以将业务逻辑与UI完全分开。 第二种方法似乎更优雅,但是这种方法有很多未解决的问题。例如:如何处理模型/数据库中的更改/添加。我们将.NET与Entity Framework结合使用来拥有强类型化的实体。我看不到如何处理一个客户所需的属性,而又另一个客户无用的属性而又不会弄乱我们的数据模型。我们正在考虑通过使用卫星表(有一个单独的表,其中特定实体的额外列与原始实体1:1映射在一起)解决数据库中的问题,但这仅是数据库。您如何在代码中处理此问题?我们的数据模型位于一个中央库中,使用该方法我们将无法为每个客户扩展。 我敢肯定,我们不是唯一一个在这个问题上苦苦挣扎的团队,我很震惊地发现关于该主题的资料很少。 所以我的问题如下: 您对高度定制的软件有什么经验,选择了哪种方法以及它如何为您工作? 您推荐哪种方法,为什么?有没有更好的方法? 您是否可以推荐有关该主题的好书或文章? 您对我们的技术环境(.NET,实体框架,WPF,DI)有具体建议吗? 编辑: 感谢所有的建议。大多数构想与我们团队中已有的构想相符,但了解您对它们的经验以及更好地实施它们的提示确实很有帮助。 我仍然不确定我们会走哪条路,也没有做出决定(单独做出),但是我会在团队中传递这一点,并且我相信这会有所帮助。 目前,男高音似乎是一个使用各种客户特定模块的单一存储库。我不确定我们的体系结构是否达到这个目标,或者我们需要投入多少资金才能使其适应要求,因此有些事情可能会在单独的存储库中保留一段时间,但是我认为这是唯一可行的长期解决方案。 因此,再次感谢您的所有回复!

4
除了男性和女性以外,是否存在性别模型的行业标准?
我正在建模一个数据库,该数据库应该用作启动公司的所有服务(如人员,用户,服务和商业数据,如优惠券,签名包等)的通用非功能性要求。 我正在考虑性别模型。在当今时代以及各国关于主观身份的法律不同的情况下,我是否应该考虑这一点,并为我的“个人”实体建模,而不仅仅是男性和女性选择? 选项包括:未定义,未回答,其他,跨性别...或我不知道的任何其他行业标准 ... 还是说LGBT人不是真正的男性或女性而冒犯了他们?

3
将用户和用户个人资料保留在不同的表中?
我在几个项目中看到,开发人员更喜欢将基本用户信息保留在一个表中(电子邮件/登录名,密码哈希,屏幕名称),而将其余非必需用户概要文件保留在另一个表中(创建日期,国家/地区等)。所谓非必需,是指仅偶尔需要此数据。明显的好处是,如果您使用的是ORM,则查询较少的字段显然是好的。但是,然后您可以将两个实体映射到同一表,这将使您免于查询不需要的内容(同时更加方便)。有人知道将这些东西放在两个表中还有其他好处吗?

8
数据库设计中的不变性
约书亚·布洛赫(Joshua Bloch)的《有效的Java》中的一项内容是,类应允许实例的变异尽可能少,最好根本不允许变异。 通常,对象的数据会保存到某种形式的数据库中。这使我开始思考数据库中的不变性,特别是对于那些代表较大系统中单个实体的表而言。 我最近一直在尝试的一种想法是尝试最小化我对代表这些对象的表行的更新,并尝试尽可能多地执行插入。 我最近正在尝试的一个具体示例。如果我知道以后可以在记录中附加其他数据,我将创建另一个表来表示该表,类似于以下两个表定义: create table myObj (id integer, ...other_data... not null); create table myObjSuppliment (id integer, myObjId integer, ...more_data... not null); 希望这些名字不是一字不漏的,只是为了说明这个想法。 这是数据持久性建模的合理方法吗?是否值得尝试限制在表上执行的更新,尤其是对于最初创建记录时可能不存在的数据填充空值?有时候这样的方法以后可能会引起严重的疼痛吗?


8
在数据库中存储地理地址/位置的通用方法是什么?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 2年前关闭。 什么是地理地址/位置的正确格式,最适合地球上的任何地址?目前,我有: 国家 市 街 数 文本数据(为简单起见) 压缩 纬度/经度 但是我相信我可以改善它:一个国家或地区或地区之类的东西。或在新加坡或香港没有区域/地区/州。 可能没有街道,但道路,林荫大道或其他东西。许多建筑物可能是复合的。可能有地板。房间号。等等....

5
重新设计数据库的最佳实践
在为应用程序设计数据库时,我知道一些通用的最佳做法,但是重新设计呢? 我正在一个负责重新设计内部业务应用程序的团队中,尽管尽管我说的是“内部”,但不幸的是,我仍然有很多很多层次的人无法与系统的实际用户联系。 当前程序以Oracle Forms形式存在,散布在许多非规范化表中,有时还有多个几乎重复的表,它们在彼此的数据上略有不同。约束通常以存储过程执行不力的形式出现。甚至类型似乎也没有正确存储。我遇到了各种各样的错误数据,Oracle似乎忽略了这些错误数据,但这些数据适合SQL Server的“导入/导出向导”。(例如,两位整数不构成完整的日期时间!) 原始程序可能要追溯到二十年前,所有原始开发人员都已经退休很久了,以至于这里的老年人也不知道他们是谁。结果,实际上也没有任何干净的要求—我们只应该复制现有应用程序的功能并保留其现有数据。 重写的最终结果将是在ASP.NET上运行的基于Web的版本,后端是MS SQL Server。 我的另外两个开发团队成员都比我大得多,都具有商业/ MIS背景,而我的则是CS。高级成员的经验几乎完全是Oracle表格,而其他成员则主要在Visual Basic中完成业务应用程序工作。尽管我的数据库背景仅限于为MySQL或SQLite中的项目设计新数据库,主要是针对我的本科课程,但我似乎是唯一拥有实际设计数据库经验的人。 我已经用C#编写了一个小程序,该程序将所有现有数据读取为中性格式,可以重新广播并放置到新数据库中。我计划在设计目标数据库之后编写加载代码,以便可以在新的规范化表中正确分割数据,以正确的顺序添加数据以遵循新的约束,等等。然后可以再次运行同一程序将生产数据复制到真正新部署的完成的重新设计中。剩下的主要工作是对数据库进行实际的重新设计。 所以我的问题的核心:从现有应用程序的数据库级别进行重新设计的最佳实践是什么?

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.