[thelist] Magic data table

Edwin Horneij ed_horneij at yahoo.com
Wed Aug 18 14:44:40 CDT 2004


--- Maximillian Schwanekamp <lists at neptunewebworks.com> wrote:

> Edwin Horneij wrote:
> 
> >He [the original developer] has created a kind of "one size fits 
> >all" meta-table that contains everything -- HTML templates, product 
> >information, user registration info, and probably a lot more.
> >
> Is there only one table in the database?  Your description seems to 
> suggest that.

There are 5-6 other tables, about half of which are empty. The ones
with data in them seem largely concerned with administrator permissions
for part of the site I don't have to worry about right now.

> >The columns are named like this: "Field_1_Name", "Field_1_Type",
> >"Field_1_Value", "Field_2_Name", and so on. Queries take the form
> >"SELECT * FROM Content WHERE Field_1_Name = 'First Name' AND
> >Field_1_Value = 'Edwin'".
> >
> >My predecessor seems to have also written PHP code that changes the
> >structure of the table where necessary. 
> >
> Crazy.  That could be useful in some instances, but the sample data
> you gave suggests this is pretty standard stuff.  Do you maintain 
> some sort of map of this super table?  Any thought to maintainability
> for future devs?

As far as I know there is no map, but I had nothing to do with the
initial development of the site. Maintainability is an issue already,
since the client wants to collect more information from registered
users than the current system is configured to gather. My instinct is
not to continue to use the current set-up, but rather to extract all
the user info while there isn't much of it and put it in its own set of
tables done the way I have been taught is standard.

> >For example, if a newly submitted value for a given entity's 
> >attribute exceeds 255 characters, the system moves all of the data 
> >for that attribute of that type of entity from the default 
> >varchar column to a text column. I _think_ it will also add new 
> >columns to accomodate more attributes than there are columns 
> >available, should that be necessary.
> >
> Maybe there is a good reason for this, but I doubt it.  Again, I can 
> think of a few instances where this sort of thing might be handy -
> where an application requires maximum flexibility in certain limited 
> instances.  Without knowing more about the app, it's hard to make 
> judgements, but Conventional Wisdom(tm) suggests that scripts should
> not be modifying table structure on-the-fly in 99.9% of cases.  After

> extended use and/or with concurrent connections, that kind of system 
> will likely slow to a crawl. 

Thank you for your input, Maximillian. The system isn't quite as crazy
as that -- in normal use the structure of the DB wouldn't be modified.
Site visitors would not have the opportunity to do anything which would
cause the system to reconfigure itself. The app is really just a pretty
ordinary web site.

I think the system as designed is overkill, but I suspect the original
developer had already built it out as an all-purpose tool. It seems
pretty solid, but I am reluctant to trust something I don't understand
well, and the client is impatient for me to start making the changes he
wants, so I am going to follow my instinct and restructure the DB along
more conventional lines.




		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 


More information about the thelist mailing list