Radical use of MySQL comments

[dhall5@gmail.com]

Hi everyone,

My company advertises "not off the shelf" programming and what we
provide can be fit to each clients needs. With that the biggest goal
I have is to have the 80% of what everyone needs ready to roll - but
make that other 20% unique to the client's project fast to turn out.

I'm about to begin programming an "editor" page that looks at the
table being worked with - and then based on column type, naming
conventions, etc - PHP draws the form with appropriate inputs for
columns. I need to put a friendly label on the field - so instead of
"StatusID" it could say "Page Status" --- my thought is to put "Page
Status" in the comments for that field and pull it out at time of
display to the user.

Pros I see in this are
Editing the database to add/edit/remove fields will also affect the
editor page at the same time
The same edit will also handle Insert/Update statements so no SQL will
need touched
Logic written 1 time for rules of how to display column inputs will
rarely if ever need touched again
Time to finish that 20% custom to each client is drastically reduced

Can you please provide cons to this idea? So far internally its been
"Thats not how its done" and I'm asking "why can't it be done?"

[C. (http://symcbean.blogspot.com/)]

Re: Radical use of MySQL comments

On 13 Feb, 17:57, "Rik Wasmus" <luiheidsgoe... @hotmail.comwro te:

On Wed, 13 Feb 2008 17:38:53 +0100, dha...@gmail.co m <dha...@gmail.c om>
wrote:
>

<snip>

>

I'm about to begin programming an "editor" page that looks at the
table being worked with - and then based on column type, naming
conventions, etc - PHP draws the form with appropriate inputs for
columns. I need to put a friendly label on the field - so instead of
"StatusID" it could say "Page Status" --- my thought is to put "Page
Status" in the comments for that field and pull it out at time of
display to the user.

<snip>

>
The problem is not this cannot be done (after all, it's basically how
PHPMyAdmin works for instance). Aside from the fact this has quite some
overhead, the problem is not all functionality can be grasped
automatically from a database/table setup/description/comments.
>

<snip>

....and others. Not very radical really.

The main problem here is how to maintain the metadata. There already
several solutions which attempt to address this specifically for PHP
(metabase/metastorage for instance). There are lots of non-language
specific tools out there (most of which use XML to describe the
structure). I'd be having a long hard look at what has been published
elsewhere before defining my own "standard".

(yeah, I know, stored procedures are a good thing).

....only if used correctly, and even then.....? Typically encapsulating
complex transactions is better done at the PHP layer - anything else
is a view. (C dons flame retardant overalls)

C.