Questions tagged «database-design»

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

15
MySQL可以合理地对数十亿行执行查询吗?
我正计划将来自质谱仪的扫描结果存储在MySQL数据库中,并想知道是否可以远程存储和分析这一数量的数据。我知道性能会因环境而异,但是我正在寻找一个大致的数量级:查询需要5天还是5毫秒? 输入格式 每个输入文件都包含一个光谱仪。每次运行都由一组扫描组成,并且每次扫描都有一个有序的数据点数组。有一些元数据,但是文件的大部分由32位或64位int或float数组组成。 主机系统 | ---------------- + ------------------------------- | | 操作系统| Windows 2008 64位| | MySQL版本| 5.5.24(x86_64)| | CPU | 2个Xeon E5420(共8核)| | 内存 8GB | | SSD文件系统| 500 GiB | | 硬盘RAID | 12 TiB | | ---------------- + ------------------------------- | 使用可忽略的处理器时间在服务器上运行其他一些服务。 文件统计 | ------------------ + -------------- | | …

8
为什么我们不应该允许NULL?
我记得读过一篇有关数据库设计的文章,并且我还记得它说您应该具有NOT NULL的字段属性。我不记得为什么会这样。 我似乎只能想到的是,作为应用程序开发人员,您无需测试NULL 和可能不存在的数据值(例如,字符串的空字符串)。 但是,对于日期,日期时间和时间,该怎么办(SQL Server 2008)?您必须使用一些历史性的或触底反弹的日期。 有什么想法吗?

12
是否应将二进制文件存储在数据库中?
在数据库中存储与数据相关的二进制文件的最佳位置是什么?你应该: 用blob存储在数据库中 使用数据库中的链接存储在文件系统上 存储在文件系统中,但重命名为内容的哈希并将哈希存储在数据库中 我没想到的事 (1)的优点(尤其是)保留了事务的原子性。代价是您可能会大大增加存储(以及相关的流/备份)要求 (3)的目标是在某种程度上保留原子性-如果您可以强制执行写入操作,则不允许更改或删除文件,并且始终具有正确的哈希作为文件名。想法是在允许插入/更新引用哈希之前将文件写入文件系统-如果此事务在文件系统写入之后但在数据库DML之前失败,则可以,因为文件系统正在“伪造”为所有存储库可能的文件和哈希-里面是否有没有指向的文件都没关系(如果小心,可以定期清理它们) 编辑: 看起来有些RDBMS以各自的方式涵盖了这一点-我很想知道其他人是如何做到的-特别是在针对postgres的解决方案中

3
使用ENUM和Integer类型的优缺点?
假设在某些随机表中,您有一列名为status的列。它的实际值将被启用或禁用。 将此列的数据类型设置为int / bool(1或零)还是ENUM将值enabled与and 一起使用会更好disabled吗?优点或缺点是什么? 假设您有4个,10个甚至更多个,而不仅仅是两个有效的状态?随着所需值数量的增加,优势和劣势会左右摇摆吗?

5
存储与计算合计值
是否有任何准则或经验法则来确定何时存储合计值以及何时动态计算合计值? 例如,假设我有一些用户可以评价的小部件(请参见下面的架构)。每次我显示一个小部件时,我都可以从Ratings表中计算平均用户评分。或者,我可以在Widget表上存储平均评分。这样可以避免我每次显示窗口小部件时都必须计算评分,但是随后,用户每次对窗口小部件进行评分时,我都必须重新计算平均评分。 Ratings Widgets --------- ------- widget_id widget_id user_id name rating avg_rating <--- The column in question

3
复合索引对第一字段的查询是否也有用?
假设我有一个包含字段A和的表格B。我在A+ 上进行常规查询B,因此在上创建了一个复合索引(A,B)。A组合索引还会仅对查询进行完全优化吗? 此外,我在上创建了索引A,但Postgres仍然仅在上将复合索引用于查询A。如果前面的答案是肯定的,那么我认为这并不重要,但是如果单个A索引可用,为什么默认情况下为什么要选择复合索引呢?

3
如何在PostgreSQL中为新列指定位置?
如果我有带有列的表: id | name | created_date 并想添加一列,我使用: alter table my_table add column email varchar(255) 然后将该列添加到该created_date列之后。 有什么办法可以指定新列的位置?例如,这样我可以在之后添加它name并得到一个像这样的表: id | name | email | created_date

10
将应用程序逻辑放入数据库层的论据是什么?
注意:programmers.se和dba.se的受众是不同的,并且会有不同的观点,因此在这种情况下,我认为重复存在什么理由或将应用程序逻辑放入数据库层是有道理的?关于程序员。 我已经找不到关于dba的讨论了,原始帖子说明了一切,所以: 大多数软件开发人员都希望将应用程序逻辑保留在应用程序层中,对于我们而言,将其保留在此处可能很自然。数据库开发人员似乎希望将应用程序逻辑作为触发器和存储过程放在数据库层中。 就个人而言,我希望在应用程序层中保留尽可能多的内容,以使其更易于调试,并使各层的职责分开。 您对此有何想法,应该或不应该在数据库层中实现什么? 注意:我不是那个问题的OP,但是保留了原来的措词。

5
数十亿行数据的最佳数据库和表设计
我正在编写一个需要存储和分析大量电气和温度数据的应用程序。 基本上,我需要存储过去几年以及成千上万个位置以后很多年的每小时小时用电量测量值,然后以一种不太复杂的方式分析数据。 我现在需要存储的信息是位置ID,时间戳(日期和时间),温度和用电量。 关于需要存储的数据量,这是一个近似值,但遵循以下原则: 20000多个位置,每月720条记录(每小时测量,每月大约720小时),120个月(十年前) )以及未来的很多年。简单计算得出以下结果: 20 000个位置x 720条记录x 120个月(10年前)= 1 728 000 000条记录。 这些是过去的记录,新记录将每月导入,因此大约每月20000 x 720 = 14400 000新记录。 总地点也将稳定增长。 对于所有这些数据,将需要执行以下操作: 检索某个日期和时间段内的数据:某个特定位置ID的所有记录,这些记录介于日期01.01.2013和01.01.2017之间以及07:00和13:00之间。 在特定日期和时间范围内进行简单的数学运算,例如,在07:00至13:00之间的5年中,某个位置ID的MIN,MAX和AVG的温度和用电量。 数据将每月写入一次,但会(至少)不断被数百个用户读取,因此读取速度显得尤为重要。 我没有使用NoSQL数据库的经验,但是从我的经验来看,它们是在此处使用的最佳解决方案。我已经阅读了最流行的NoSQL数据库,但是由于它们完全不同,并且还允许非常不同的表体系结构,因此我无法决定使用哪种最佳数据库。 我的主要选择是Cassandra和MongoDB,但由于我的知识非常有限,并且在涉及大数据和NoSQL方面没有实际经验,因此我不确定。我还阅读到PostreSQL也可以很好地处理此类数据。 我的问题如下: 我是否应该将NoSQL数据库用于如此大量的数据。如果不能,我可以坚持使用MySQL吗? 我应该使用哪个数据库? 我应该将日期和时间保留在单独的索引索引(如果可能)列中,以便在特定的时间和日期期限内快速检索和处理数据,还是可以通过将时间戳记保留在单个列中来完成此操作? 时间序列数据建模方法在这里是否合适,如果不合适,您能否为我提供良好表设计的指导? 谢谢。

5
此键值数据库模式有名称吗?
我们处理来自客户的例行数据馈送,该客户只是将其数据库从一种看起来很熟悉的形式(每个实体一行,每个属性一列)重构为一个我不熟悉的形式(每个实体每个属性一行,): 之前:每个属性一列 ID Ht_cm wt_kg Age_yr ... 1 190 82 43 ... 2 170 60 22 ... 3 205 90 51 ... 之后:所有属性的一列 ID Metric Value 1 Ht_cm 190 1 Wt_kg 82 1 Age_yr 43 1 ... 2 Ht_cm 170 2 Wt_kg 60 2 Age_yr 22 2 ... 3 Ht_cm …

9
您应该在编写应用程序代码之前设计数据库吗?
设计数据库的最简单,最有效的方法是什么?在我看来,应用程序的数据存储设计有两个选项: 在编写任何应用程序代码之前,请尽可能最好地设计数据库。这为您提供了可以使用的基本数据结构的优点。我认为,这样做的缺点是您将进行很多更改,因为应用程序的具体细节会影响整个应用程序开发周期中数据的更改内容/位置/方式。 随着应用程序的实现,设计数据库。当您在编写应用程序时需要一些数据库对象时,可以与应用程序并行(按时间顺序)开发数据库。我所看到的好处是减少了对数据库结构的更改。缺点是应用程序代码和数据库开发之间的时间和开发工作的划分。 根据您的经验,您发现什么是最有效和高效的方法?

7
编写一个简单的银行架构:如何使我的余额与他们的交易记录保持同步?
我正在为一个简单的银行数据库编写模式。基本规格如下: 数据库将针对用户和货币存储交易。 每个用户每种货币都有一个余额,因此每个余额只是针对给定用户和货币的所有交易的总和。 余额不能为负。 银行应用程序将专门通过存储过程与其数据库进行通信。 我希望该数据库每天可以接受成千上万的新交易,并且可以平衡更高数量级的查询。要非常快地用完余额,我需要预先对其进行汇总。同时,我需要保证余额永远不会与其交易历史相矛盾。 我的选择是: 有一个单独的balances表,然后执行下列操作之一: 将交易应用到transactions和balances表。TRANSACTION在存储过程层中使用逻辑,以确保余额和交易始终保持同步。(由Jack支持。) 将交易应用到transactions表格,并使用触发器balances为我更新交易金额。 将事务应用于balances表,并具有一个触发器,该触发器transactions为我在表中添加一个具有事务量的新条目。 我必须依靠基于安全性的方法来确保在存储过程之外无法进行任何更改。否则,例如,某些过程可能会直接将事务插入transactions表中,而根据计划1.3,相关余额将不同步。 有一个balances索引视图可以适当地汇总事务。存储引擎保证余额与事务保持同步,因此我不需要依靠基于安全性的方法来保证这一点。另一方面,由于视图-甚至是索引视图-都没有CHECK约束,因此我不能再将余额强制为非负数。(由Denny支持。) 仅具有一个transactions表,但具有一个附加列来存储该交易执行后立即生效的余额。因此,用户和货币的最新交易记录也包含其当前余额。(下面由安德鲁建议;由garik提出。) 当我第一次解决这个问题时,我阅读了这 两个讨论并决定选择2。作为参考,您可以在此处看到其基本实现。 您是否设计或管理了这样的具有高负载配置文件的数据库?您如何解决此问题? 您认为我做出了正确的设计选择吗?我有什么要记住的吗? 例如,我知道对transactions表的架构更改将需要我重建balances视图。即使我在归档事务以保持数据库较小(例如,通过将它们移动到其他地方并用汇总事务替换),每次架构更新都必须从数千万个事务中重建视图,这可能意味着每个部署的停机时间会大大增加。 如果要使用索引视图,如何保证没有余额是负数? 归档交易: 让我详细说明一下归档事务和上面提到的“摘要事务”。首先,在这样的高负载系统中,定期归档将是必要的。我想保持余额与交易记录之间的一致性,同时允许将旧交易移至其他位置。为此,我将使用每位用户和货币金额的摘要替换每一批已归档的交易。 因此,例如,以下交易清单: user_id currency_id amount is_summary ------------------------------------------------ 3 1 10.60 0 3 1 -55.00 0 3 1 -12.12 0 已归档并替换为: user_id currency_id amount is_summary ------------------------------------------------ 3 1 -56.52 1 …

1
如何在DATABASE vs SCHEMA上为用户管理默认特权?
我想将一个相当简单的内部数据库驱动的应用程序从SQLite3迁移到PostgreSQL 9.3,并在我进行操作时加强数据库中的权限。 该应用程序当前包含一个用于更新数据的命令。和一个查询它。当然,我还需要以其他方式维护数据库(创建新表,视图,触发器等)。 虽然此应用程序最初将是服务器上唯一托管的应用程序,但我更倾向于假设将来它可能与其他数据库一起托管在服务器上,而不是在必要时稍后进行争夺。未来。 我认为这些是相当普遍的一组要求,但是我很难找到一个简单的教程来解释如何使用这种用户/特权分离在PostgreSQL中设置新数据库。有关组,用户,角色,数据库,架构和域的参考详细介绍。但我发现它们令人困惑。 到目前为止,这是我尝试过的内容(来自psql“ postgres”): CREATE DATABASE hostdb; REVOKE ALL ON DATABASE hostdb FROM public; \connect hostdb CREATE SCHEMA hostdb; CREATE USER hostdb_admin WITH PASSWORD 'youwish'; CREATE USER hostdb_mgr WITH PASSWORD 'youwish2'; CREATE USER hostdb_usr WITH PASSWORD 'youwish3'; GRANT ALL PRIVILEGES ON DATABASE hostdb TO hostdb_admin; GRANT CONNECT …

6
每个客户创建数据库会遇到什么问题?
我记得在stackoverflow播客中,Fog Creek为每个客户使用了一个数据库,用于Fogbugz。我认为这意味着Fogbugz On Demand服务器具有成千上万个数据库。 我们才刚刚开始开发Web应用程序,并且有类似的问题要解决(很多拥有自己孤立数据的客户)。 我对每个客户使用数据库有什么问题?我该如何解决? 我的初步想法 每个客户的数据库优势 更简单的数据库架构 更简单的备份-您可以依次备份每个客户,而不会真正影响其他客户。 轻松导出给定的客户数据。 更好的缓存性能-写入更活跃的表之一只会影响执行写入操作的单个客户。 跨硬件更容易扩展。例如,当我们需要从1台服务器转到2台服务器时,我们只需将一半的客户转移到新服务器上。 缺点 MySQL可以应付5,000个数据库吗?性能会糟透吗? 对模式的更改可能很难在所有数据库中复制出来。我们真的真的需要为此制定一个自动化计划,例如对架构进行版本控制以及一个脚本,该脚本可以了解如何将数据库从一个版本移植到另一个版本。 做所有客户共同的事情可能很尴尬或不可能 与上述类似,但是我们想要对所有客户执行的任何分析都是不可能的。例如,我们应如何跟踪所有客户的使用情况?

12
DBA如何才能更“程序员友好”?
关于问题“在数据库层中放置应用程序逻辑或将其放置在数据库层中的参数是什么?”的dba.se版本和programmers.se版本的答案和注释。在某些工作场所中,DBA和程序员之间的鸿沟非常明显。 在这样的问题上,DBA有什么不同的方法可以更好地与程序员合作? 我们应该吗: 研究程序员使用的工具和语言,以了解他们面临的困难,尤其是在使用精心设计的数据库时? 鼓励程序员对数据库进行更好的教育,以及在数据库级别拥有业务逻辑的好处? 更改我们定义数据接口的方式-例如通过使用对程序员更友好的事务性API(例如,针对向后兼容性等问题)?

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.