title: Relational database design with unknown number of attributes at the beginnig
body: <p>I'm developing a document management system for my graduation project.</p>
  
  <p>In this project, users are adding documents' metadata into my "documents" table in a relational database.</p>
  
  <p>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".)</p>
  
  <p>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.</p>
  
  <p>The question is how I should store this kind of data in my relational database system? (Postgres in this case.)</p>
  
  <p>I do some research, found some solutions but I cannot decide what to do.</p>
  
  <p>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?</p>
  
  <p>Or should I crete a new table for each document type with its defined attributes? and then union them when requested by users?</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>I can provide more information if requested.</p>
  
  <p>Thanks.</p>