Hi,
Zeeshan is proposing a new table to store user preferences: http://zixan.info/2009/06/04/gsoc-week-two-progress/#comments
Michal answers in the blog that this does not scale. When looking at Zeeshan's proposal, I had the same idea for a moment. However, after some researches, I am tempted to reject Michal's proposal.
Michal's proposed solution (a table with key values) is also called the EAV (entity-attribute-value) model. http://en.wikipedia.org/wiki/Entity-attribute-value_model#Downsides
This is advocated as a design flaw by some experts, see the comments here: http://www.devshed.com/showblog/22280/Database-Design-Using-KeyValue-Tables/
http://decipherinfosys.wordpress.com/2007/01/29/name-value-pair-design/
Marc
Hi,
Sorry I answered on the blog too - Michal's proposal has been clarified already.
In your NavigationBarIconic example you could consider bitwise stuff 0 - nothing 1 - option 1 2 - option 2 3 - option 1 and 2 4 - option 3 5 - option 1 and 3 etc
- Mike
On 5/06/2009 11:25, Marc Delisle wrote:
Hi
Dne Thu, 04 Jun 2009 19:25:40 -0400 Marc Delisle marc@infomarc.info napsal(a):
I know it's not perfect solution. But when I look at our configuration file, we have far too many options, to represent them as columns in table. Furthermore adding new option would mean to force users to upgrade the table.
Personally, I do not mind implementing any of the structures.
In my opinion, upgrading should not really be a problem. I will be writing a little tool to auto upgrade the table. And I don't think we will be adding new settings to be tracked every so often, so it will just be a regular upgrade.
Sure, there are several settings in the configuration file that may complicate the table structure.
Thanks!
-------------------------------------------------- Best regards, Zeeshan Mughal Email: zeeshanmughal@ieee.org Web: http://www.zixan.info
On Fri, Jun 5, 2009 at 1:35 AM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Fri, 5 Jun 2009 01:54:28 -0400 Zeeshan Mughal zeeshan.jp@gmail.com napsal(a):
New settings usually come in each "big" release (second number changes), what I think is quite often for forcing table upgrades. So far we stick with same table structures for quite a long time...
Hi
Dne Mon, 08 Jun 2009 11:10:06 -0400 Marc Delisle marc@infomarc.info napsal(a):
Sorry Michal, I don't get your point. Are you saying that auto-upgrade would not be appropriate?
With our current suggested way of creating pma user there is no way to do autoupgrade easily - pma user does not have enough privileges, so you need to ask user for more privileged account to do the upgrade.
Michal Čihař a écrit :
Yes there are downsides for each alternative. Another downside for the EAV model is that at user login (session initialization) we need to read all the rows holding the user prefs for this user, instead of just one read if each option has its own column.
As mentionned in one of the links I gave, the EAV model also makes it difficult to code the possible choices for an option, for example into an ENUM.
About upgrading, I expect Zeeshan to implement a feature to auto-create and auto-upgrade the table (which could be extended to all of our pmadb tables).
Marc
Hi
Dne Fri, 05 Jun 2009 05:32:02 -0400 Marc Delisle marc@infomarc.info napsal(a):
With index on login name, selecting several rows should be quite cheap.
Okay, I probably can live with either of solutions. Both have downsides and advantages.
It should be coded with this in mind.
:-) -------------------------------------------------- Best regards, Zeeshan Mughal Email: zeeshanmughal@ieee.org Web: http://www.zixan.info
On Mon, Jun 8, 2009 at 11:18 AM, Marc Delisle marc@infomarc.info wrote:
-
Marc Delisle -
Michal Čihař -
Mike Cochrane -
Zeeshan Mughal