Re: What are the consequences of a bad database design (never seen that before !)

On Wednesday 13 April 2005 01:21, Jinane Haddad wrote:
> Thanx guys for the advices.
>
> i think i will have to find some "POLITICAL" approach in order to
> restructure the existing database, which i am not so good at but worse
> trying. Note that even the code is Bad (they are using PHP for a big
> application - no object oriented design - a lot of code redundancy ...).
>
> However, it seems difficult to fix the database bit by bit cause as far as
> i have seen one or more primary TAble(s) are missing !! So instead of
> using an ID, 3-4 fields are being rewritten in almost every table ! So if i
> have to build the primary tables, i have to change all the other tables
> replacing the combined fields with the corresponding ID ... and there is
> many others modifications which could lead to eventuel code modification
> even if i change the Views in order to mask the changes. (Thanx god they
> are using Views !!!!!)
>
> Anyways it seems i have a major modification that will need time and they
> are giving me Time for adding modules not the time for fixing the existing.
>
> So basically what is happening is du to the bad database and code design:
> Writing a simple Task is becoming difficult and requires minimum 4 times
> more time than in the case of a good design.
> So development time is wasted, and data Corrections are being done almost
> every day by the stuff here ...
>

Remember that the goal is to fix everything *now*... but fix it bit by bit.
The first time you would need to access those 3-4 fields in any new module,
rather than adding them into a new tables, rework the schema to be
normalized...even if you cant pull those 3-4 fields out of every table, pull
it out of a core few tables and use your new key in your new tables so that
you start down the path to a better schema.

But be careful how you approach things... have a 3-4 field primary key in 10
different tables is perfectly fine within the relational model... in fact
some purists would even argue for something like that rather than creating a
surrogate key... so just because they have done that doesn't mean that they
are wrong even if your way is better.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL