Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux