|
|
Posted by tartagoo@gmail.com on 10/06/07 15:37
What if you used only one table with more generic colums?
Let's say we have a table named "entities" (just to mean no matter if
we have to do with users, clients, accounts etc.).
The columns could be: id, parent, ref, type, data.
Ex. of contents:
1, 0, 'user', '', ''
2, 1, 'email', 'email', 'username@provider.com'
3, 1, 'password', 'password', 'akfgKJ8'
4, 1, 'nick', 'text', 'bobby'
To retrieve the email of the user who typed in nick and password,
we'll write something like "select data from entities where parent =
(select e1.parent from entities as e1 join entities e2 on e1.parent =
e2.parent where e1.data = '$nick' and and e1.ref = 'nick' and e2.data
= '$password' and e2.ref = 'password') and ref = 'email'.
That seems a bit complicated but the pro is you don't have to worry
about witch and how many columns because every attribute become an
entity child of another entity, where id and parent colums are used as
internal references and the name of the attribute is the ref.
Data should be a longtext type or even a binary one if you're going to
use this table to store e.g. images as attributes of a certain entity.
Of course this kind of table could host any kind of things.
While I think this method is easy to handle from the programmer's
point of view, what I'm tryng to understand is if it is too expensive
in terms of resources/performances.
Navigation:
[Reply to this message]
|