Questions tagged «database-design»

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

1
PostgreSQL上金融应用程序的身份验证方法的选择
首先介绍一些背景。 LedgerSMB项目是在PostgreSQL上运行的开源财务会计软件项目。我们在用户定义的函数中实现了大量的业务逻辑,这些逻辑充当程序对象方法与数据库行为之间的主要映射工具。当前,我们将数据库用户用作身份验证用户,部分是通过选择(这允许集中的安全逻辑,以便可以编写其他工具并重复使用授予用户的权限),另一部分是根据需要(在从SQL-Ledger分叉之后)在该代码库上加装安全性的选择不多)。 这使我们可以访问PostgreSQL可以访问的合理数量的单点登录选项,从LDAP到Kerberos5。我们甚至可以在涉及密码的情况下使用PAM。它还允许我们在与其他应用程序集成或允许其他客户端界面时重用权限。对于财务会计应用程序来说,这似乎是一个净赢。 涉及明显的成本。对于Web应用程序,我们非常受支持的http auth类型限制。例如DIGEST完全被淘汰。BASIC可以正常工作,并且我们可以很容易地实现KRB5(我计划对此提供支持,并在1.4版本开箱即用)。虽然很可能会在必要时对它们进行垫片化(例如,BASIC +带有用户名和特定根ca的cn的cn的客户端SSL证书),但不能直接在此上正确地管理非常强大的身份验证措施。 同时,我们受到了很多批评,大多数是来自开发人群,还有一些是来自dba的批评,他们告诉我应用程序应该是安全屏障,而不是数据库。我仍然认为,较小的安全范围通常更好,重用业务逻辑和安全逻辑在一起,并且重用业务逻辑而不在同一级别重用安全逻辑使我感到非常危险。该程序。 我在这里错过任何重大的权衡吗?是否有我没有考虑的陷阱?

2
设计用户认证(角色和权利)模块
我正在尝试为MS SQL Server数据库建模用户身份验证模块,该模块将成为Delphi UI应用程序的后端。基本上,我想拥有一个用户帐户,其中该用户仅属于一个组。一个组可以具有“ n”个权限。 我还想将密码历史记录添加到数据库中,因为将要求用户根据应用程序设置(例如,每90天)更改其密码。 我也想在用户每次登录和注销时都记录一个事件。我将来可能会将其扩展到其他事件。 在下面,您会发现我的第一个裂缝。请让我知道任何改进的建议,因为这是我第一次这样做。 您是否发现需要其他属性以实现基于角色的安全性以及密码规则/有效期限的约束?


4
发布的概念架构有多少安全风险?
我向政府机构的信息系统索要概念性方案以进行研究。我的请求已被拒绝,原因是存在安全风险。 我确实没有丰富的数据库经验,所以我无法验证该说法。公开您的架构真的有那么大的安全风险吗?我的意思是,它们是非常抽象的,与硬件和软件实现分离。对于攻击者如何利用概念性模式的解释将不胜感激。谢谢。

2
问卷数据库设计-哪种方法更好?
我有一个长长的html页面,几组问题分成小部分(一页中大约有15个子部分),问题总数约为100个问题:输入,选择,复选框,单选按钮,文本区域,和文件上传。一个问题可以包含许多答案,这些答案可以从一组复选框,一组选择列表,一组多重选择中获得,也可以全部组合成一个答案。我以为我会在下面使用这种数据库设计,但是最近发现这毕竟不是一个好方法。 一位客户只能回答一组问题:每100个问题一位客户。 对于旧方法,我不在数据库中保留问题,而是在PHP编码中将其分配为常量。问题是我必须比较PHP中的问题,以使其与数据库中的答案同步。如果从PHP更改/删除/移动了一个问题,我肯定会迷失它与问卷数据库中的答案。更好的解决方案? 我能否将从多个元素中获得的多个答案作为一个答案保存在一个字段中?如何检索此字段并再次显示它以供客户在表单上查看? 我应该选择以下哪个选项? 选项1:旧方法(1张桌子) 表格:问卷 编号(PK) 客户ID 状态 A1 A2 A3 。 。 。 A100 选项2:新方法(2张表) 表格:问题 QID(PK) 问题(varchar) 表格:答案 援助(PK) 客户ID QID(int) 答案(varchar) 还是选项3?

2
无模式/灵活+ ACID数据库?
我正在考虑将基于本地(本地安装)的VB应用程序(发票+库存)重写为面向小型企业客户的基于Web的Clojure应用程序。我打算将此作为SaaS应用程序提供给类似行业的客户。 我正在查看数据库选项:我的选择是RDBMS:Postgresql / MySQL。我可能会在第一年扩大到400位用户,通常每位用户每天20-40个页面浏览量/每天-主要用于非静态视图交易。每个视图将涉及获取数据和更新数据。必须符合ACID(或我认为)。因此交易量并不大。 毫无疑问,根据我的喜好选择这两种方法,但是对于这一要求,我认为这是SaaS应用程序的典型要求:随着我添加更多的客户/用户以及每个客户的需求,架构将发生变化。不断变化的业务需求(刚开始我会提供一些有限的灵活性)。由于我不是数据库专家,根据我的想法和所读的内容,我可以通过多种方式来处理: 在MySQl / Postgresql中进行传统的RDBMS模式设计,其中一个DB托管多个租户。并在每个表中添加足够的“自由浮动”列,以允许将来随着我添加更多客户或现有客户的更改而进行更改。每次对模式进行小的更改时,将更改传播到数据库中可能会有不利之处。我记得读过一篇文章,在Postgresql模式中更新可以实时完成而无需锁定。但是不确定,在这个用例中它有多痛苦或有多实用。而且,由于架构更改可能还会引入新的/次要的SQL更改。 有一个RDBMS,但是以灵活的方式设计数据库模式:具有接近实体属性值或仅作为键值存储。(例如,工作日为FriendFeed) 将整个事物作为对象存储在内存中,并定期将它们存储在日志文件中。(例如,edval,lmax) 选择NoSQL数据库,例如MongoDB或Redis。但是根据我的收集,它们不适合此用例,也不完全符合ACID。 寻找一些新的SQL Db,例如VoltDb或JustoneDb(基于云),它们保留SQL和ACID兼容行为,并且是“新一代” RDBMS。 我看了neo4j(graphdb),但不确定是否适合此用例 在我的用例中,除了可伸缩性或分布式计算之外,我还在寻找一种更好的方法来实现“模式中的灵活性+ ACID +一些合理的性能”。我在网上可以找到的大多数文章都谈到模式的灵活性,这是导致性能(在NoSQL DB的情况下)和可伸缩性的原因,而忽略了ACID /事务。 这是“模式灵活性与ACID”事务的“或”案例,还是有更好的出路?

1
日期范围的唯一性约束
考虑具有prices以下列的表: id integer primary key product_id integer -- foreign key start_date date not null end_date date not null quantity integer price numeric 我希望数据库执行以下规则,即在日期范围内(通过where <date> BETWEEN start_date AND end_date)某种产品在特定数量上只能有一个价格。 这种基于范围的约束可行吗?

1
了解通知系统
我一直在研究如何在SE和其他地方构建通知系统,发现自己对解决方案很感兴趣,该解决方案是此处接受的答案:https : //stackoverflow.com/questions/9735578/building-a-notification-system 使用这个结构: ╔═════════════╗ ╔═══════════════════╗ ╔════════════════════╗ ║notification ║ ║notification_object║ ║notification_change ║ ╟─────────────╢ ╟───────────────────╢ ╟────────────────────╢ ║ID ║—1:n—→║ID ║—1:n—→║ID ║ ║userID ║ ║notificationID ║ ║notificationObjectID║ ╚═════════════╝ ║object ║ ║verb ║ ╚═══════════════════╝ ║actor ║ ╚════════════════════╝ 通知是关于某人(演员)更改(动词=添加,请求..)并报告给用户(主题)的某事(对象=事件,友谊..)。这是规范化的数据结构(尽管我使用过MongoDB)。您需要通知某些用户有关更改。因此,这是每位用户的通知。这意味着,如果有100位用户参与,您将生成100条通知。 起初我以为我了解这种方法,但是当我准备开始实施它时,我意识到我显然不太了解它。关于答案的最后几条评论是来自其他用户的问题,这些用户也难以理解解决方案。 我不确定这是否是我最终会遵循的模型,但是鉴于它所拥有的支持者数量,我相信这对我有所帮助,我当然希望了解更多。我希望这对于其他在掌握该解决方案方面遇到困难的人也将是有用的(顺便说一句,我没有足够的互联网积分就该问题的答案发表评论,其他任何人都可以做!) 问题 如果我理解正确,则notificationObjectID是指向notification_object表的外键,而notificationID是指向通知表的外键。似乎object应该是外键,引用通知所涉及的数据库条目的ID(例如特定事件或发布),但是我们是否不需要另一个字段来指示ID属于哪个表? 作者写道 notification_object.object标识更改类型,例如字符串“ friendship”。我所讨论的对更改对象及其额外数据的实际引用位于notification_change.notificationObjectID中。 这对我来说似乎没有意义。对象是一个字符串(枚举?),notificationObjectID是一个外键,指向通知所针对的对象?那么中间表和右边表是如何连接的呢? 似乎中间表指定了通知涉及的对象(或对象类型),例如事件或帖子。然后,在notification_change中可以有许多条目指向相同的对象类型,这使我们可以捆绑通知(例如“在X的墙上张贴了25位用户”)-因此,中间表和右表之间是1:n关系。 但是为什么左表和中间表之间存在1:n关系?我们是否要给“ 25位张贴在Sam墙上的用户”和“玛丽更新了她的“星期五野餐”事件”使用相同的通知ID?如果同一用户的所有通知都具有相同的通知ID,为什么我们甚至需要剩下? 表演问题-说约翰对玛丽的野餐活动发表评论。在创建notification_change条目之前,我们似乎需要进行查找以查看Mary's Picnic 的notification_object是否已经存在。这会对性能产生负面影响,还是非问题?继续前一段的问题,我们怎么会知道哪个通知条目指向notification_object什么?

1
修复表结构以避免出现“错误:重复的键值违反唯一约束”
我有这样创建的表: -- -- Table: #__content -- CREATE TABLE "jos_content" ( "id" serial NOT NULL, "asset_id" bigint DEFAULT 0 NOT NULL, ... "xreference" varchar(50) DEFAULT '' NOT NULL, PRIMARY KEY ("id") ); 稍后,插入一些指定ID的行: INSERT INTO "jos_content" VALUES (1,36,'About',...) 稍后,将插入一些没有id的记录,它们将失败并显示错误: Error: duplicate key value violates unique constraint。 显然,id被定义为一个序列: 每个失败的插入都会增加序列中的指针,直到它递增到不再存在的值并且查询成功为止。 SELECT nextval('jos_content_id_seq'::regclass) 表定义有什么问题?解决此问题的明智方法是什么?


2
有关关系数据库中的查找表的最佳实践是什么?
查找表(或某些人称为代码表)通常是可以为特定列提供的可能值的集合。 例如,假设我们有一个查找表party(用于存储有关政党的信息),该表具有两列: party_code_idn,其中包含系统生成的数值,并且(缺少业务域的含义)可以用作实键的替代。 party_code是表的实键或“自然”键,因为它维护具有业务域内涵的值。 让我们说这样的表保留了以下数据: +----------------+------------+ | party_code_idn | party_code | +----------------+------------+ | 1 | Republican | | 2 | Democratic | +----------------+------------+ 在party_code列,这使价值“共和”和“民主”,在工作台的真正的关键,是建立了一个独特的约束,但我需要添加的party_code_idn,它定义为表(的PK虽然,从逻辑上说,party_code可以用作主键[PK])。 题 指向事务表中的查找值的最佳实践是什么?我是否应该建立外键(FK)引用(a)直接指向自然和有意义的值,或者(b)替代值? 例如,选项(a), +---------------+------------+---------+ | candidate_idn | party_code | city | +---------------+------------+---------+ | 1 | Democratic | Alaska | | 2 | Republican | Memphis | …

2
条件外键关系
我目前在两个实体之间有一个外键,我想使该关系以表之一的entityType为条件。这是表格的层次结构,这是通过FK从孩子到父母的折算完成的 Store / \ Employees \ TransactionalStores / | \ Kiosks | BrickMortars Onlines 我目前有从员工到商店的FK关系 ALTER TABLE Employees ADD CONSTRAINT Employee_Store FOREIGN KEY (TransStoreId) REFERENCES TransactionalStores(StoreId) 我想添加条件: WHERE TransactionalStores.storeType != 'ONLINE_TYPE' 这是否可能,或者我必须将TransactionalStores分为两个新的子类型(例如PhysicalStores和VirtualStores)

1
如何管理31亿行数据?
我目前的任务是为相对大量的数据实现存储模式。首先将访问数据以确定当前data point值,但我还需要跟踪过去六个月的数据趋势/分析历史。 添加了最近的要求以跟踪过去一小时的min/ max/ sum值。 注意:理想情况下,我想考虑使用MongoDB选项,但是我需要证明我已经首先用尽了SQL-Server选项。 数据 下表代表主要数据源(最常查询)。该表将有大约五百万行。在初始数据加载之后,数据更改将主要是UPDATE带有非常偶然的INSERT语句的语句。我已选择将数据聚类,dataPointId因为您将始终选择all values for a given data point。 // Simplified Table CREATE TABLE [dbo].[DataPointValue]( [dataPointId] [int] NOT NULL, [valueId] [int] NOT NULL, [timestamp] [datetime] NOT NULL, [minimum] [decimal](18, 0) NOT NULL, [hourMinimum] [decimal](18, 0) NOT NULL, [current] [decimal](18, 0) NOT NULL, [currentTrend] [decimal](18, 0) …

2
从传感器阵列存储大量数据
我受命实施一个解决方案(应用程序和数据库),以存储来自巨大传感器阵列的数据样本。该阵列目前由大约20,000个传感器组成,但是很快就会增长到多达100,000个传感器。每个传感器每10秒发送一次数据样本,每个样本的大小为28个字节。 这样求和会导致: 每个传感器每天8640个样本 每个传感器每天242kB的数据 每天8.64亿个样本 现在,我一直在想最好的方法是存储/检索数据?在指定了软件之后,我“加入”了这个项目,因此需要使用SQL Server在Windows平台上实现它。 我目前的解决方案是创建一个具有两个表的数据库来存储数据样本。第一个用作第二个的索引,第二个以每个传感器每天的基础将整理后的样本存储在二进制字段中: Table 1: RecordID - BigInt - Identity SensorID - BigInt - Primary Key Date - DateTime - Primary Key (yyyy-mm-dd) Table 2: RecordID - BigInt - Primary Key (from an insert into Table 1) Data - Binary 基本上,我会将所有传感器的样本写入临时文件(每个传感器1个)。每天结束时,我将在表1中创建一个条目,使用生成的RecordID并将文件转储到表2的“数据”字段中。 这样,我最终每天只向该表添加100,000个条目,而不是8.64亿个条目。数据应该在LAN或高速WAN上可用,因此可以全天检索传感器数据。 尽管必须存储所有数据,但大多数数据可能永远不会被读取。因此,在表上读取的数量将不会比写入的数量多得多。 我知道我可以通过仅存储数据文件的路径来使用文件系统来实现某些功能,但是我读到SQL Server的性能优于NTFS,而您的二进制字段则少了256kB。(在256kB和1MB之间存在一个灰色区域,而对于二进制大小> …

6
在MySQL中拆分表。好的做法?
我已经开始研究一个现有项目,并且以前的开发人员已将一个表拆分为10个具有相同模式但数据不同的单独表。 这些表如下所示: [tableName_0] [tableName_1] [tableName_2] [tableName_3] [tableName_4] [tableName_5] [tableName_6] [tableName_7] [tableName_8] [tableName_9] 主键是一个整数id字段。该应用程序使用哈希算法(idmod 10)来知道在查找时要访问哪个表。例如id= 10将导致[tableName_0]。 这些表加起来可能有100,000行,并且增长率相对较低。 因此,我的问题是,这是否是可行的解决方案,或者即使在任何情况下都是好的做法。我的理论是推动将它们组合在一起,因为这样会使事情变得更容易,直到UNIONs等。主要缺点是更改所有应用程序代码以及从长远来看是否值得。

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.