0

I'm trying to find the best solution for my database-design problem, I am open to any suggestions :

Database schema

I have a table Element composed of sub elements, the relation between them is M:N so I need an intersect table for each new sub element.

I can have other tables (like Element2) that will use different sub components The main difference between Element and Element2 is the set of subElements that they will use.

So far so good.

Now the problem :

I have to design a database that can have 100+ Element-like tables, moreover I can have 100 subElements per table (so 100 relations, 100 intersect tables...)

So with 10 000 tables for this configuration, I'm thinking about a bad design or a limit of the relational model...

Any advice on this ?

Thanks

user3367852
  • 1
  • Did you consider to use a graph database? – Philipp Mar 01 '14 at 13:42
  • If I can find a nice example of this problem with a graph database or nosql, I'll take it :) – user3367852 Mar 01 '14 at 14:19
  • 2
    Perhaps you could tell us the original problem, with real table names, so that we can help you find a better solution. – Neil McGuigan Mar 01 '14 at 19:04
  • Do all Element tables have the same structure? same attributes? If so, is this also true for Sub-Element tables? If so, why not just have a single set: i.e. Element, Sub-Element and Membership tables? You can always denotes the type/sub-type using additional fields. – Darius X. Mar 03 '14 at 20:34
  • They don't, this is the main problem – user3367852 Mar 08 '14 at 17:34

0 Answers0