开始时属性数量未知的关系数据库设计
我正在为我的毕业项目开发一个文档管理系统。
在这个项目中，用户将文档的元数据添加到关系数据库中的“文档”表中。
当然，有不同类型的文档，如信件、账单等。因此，每种文档类型都有不同的属性集。 （当然还有一些常见的属性，例如“作者”。）
并且用户能够使用新的属性集定义新的文档类型（或者他们可以使用用户先前定义的现有属性）。当然，用户可以在插入数十个文档后添加或删除属性。
问题是我应该如何将这种数据存储在我的关系数据库系统中？ （本例中为 Postgres。）
我做了一些研究，找到了一些解决方案，但我无法决定该怎么做。
我是否应该有一个基本文档表，并且对于每个新添加的属性，我应该创建一个单独的表（docID，值），然后在用户请求时加入它们？
或者我应该为每种文档类型及其定义的属性创建一个新表？然后根据用户的要求将它们联合起来？
或者我应该创建一个相对较大的表，比如说 200 个整数、200 个 varchar、200 个日期、200 个浮点数等，并将定义映射到每个文档类型的这些列。
作为最初的要求， 用户应该能够以任何方式订购、过滤（搜索）文档以获得某种报告。 这些文档及其属性将具有访问权限，我的意思是，它们将与我的数据库中的其他表有关系。
我在这里主要考虑的不是开发的难易程度。性能和功能要求是最重要的。 因为，在我的演示中，我应该有一个数据库，其中至少已插入 100 万个文档。
如果需要，我可以提供更多信息。
谢谢。
I'm developing a document management system for my graduation project.
In this project, users are adding documents' metadata into my "documents" table in a relational database.
And of couse, there are different kind of documents, like letters, bills etc. Therefore they have different set of attributes for each kind of document type. (and of course some common attributes too like "author".)
And users are able to define new document types with new set of attributes (or they can use existing attributes which are previously defined by the users). And of course users can add or remove attributes after dozens of documents inserted.
The question is how I should store this kind of data in my relational database system? (Postgres in this case.)
I do some research, found some solutions but I cannot decide what to do.
Should I have a base documents table, and for each newly added attribute, I should create a seperate table (docID, value) and then join them when requested by users?
Or should I crete a new table for each document type with its defined attributes? and then union them when requested by users?
Or should I create a relativly big table, with let say, 200 ints, 200 varchars, 200 dates, 200 floats etc. and them map definitions to these columns for each document type.
As a initial requirement,
user should be able to order, filter (search) documents to get some kind of reports over it by in any way.
And these documents and their attributes will have access rights, I mean, they will have relations with other tables in my database.
My main consideration in here is not the ease of development. Performance and functional requirements are most important ones.
Because, In my demonstration, I should have a database with at least 1 million documents already inserted to it.
I can provide more information if requested.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一张桌子存放文件。
一张表存储元数据（document_id、key、value）。
一次连接即可获取一份文档及其所有元数据。
One table stores the documents.
One table stores the metadata (document_id, key, value).
One join gets you a document and all its metadata.