Firstly, MJ Ray Wrote:
What the hell are you doing if you expect to do more than 8k in a single row? If it's a single large object, you should use the particular support for it (which I admit I'm bad at using). If it's really unavoidable, you can change that limit to something larger by recompiling.
And Then, Alexis Lee Wrote:
Some People (those who 'picked up database design as they went along'), like to have all the data in a single table. Lots of fields. It does
reduce
joins... <wince>
Incidentally, Martyn, I make the above comment assuming such a design has been forced upon you, not that you are one of the Some.
And In Defense, I Write:
I DID pick up Database design as I went along, I first started using Pick/D3 on Linux (back in 96 I think?) which was my first introduction to relational database design.
Although I doubt I am even an adequate database designer (having little "real-world" experience) I am not a person who likes large data tables, in fact I have a habit of creating more tables than most people would ever care to count (I believe it's the database equivalent of Sadomasochism?)
However, in this particular case it is a single large text file containing legal information/requirements/building regs/energy conservation regs etc. and all those lovely clauses that solicitors love connecting to each particular building we are involved in the construction of.
Many can be split down but some are SO big and cumbersome that I decided (with time restrictions imposed - my only real defense against ignorance here) a single table per contract would be the easiest way to go.
However, if someone wishes to enlighten the un-enlightened on the best way to handle such volume I would be most appreciative (the IT department here is just 1 person - ME so research time is a precious commodity).
I therefore enter a plea of "guilty with extenuating circumstances".
Cheers for the advice to all though. Think I will 'play' with PostgreSQL tonight. Good job the coffee machine is free-vend.
Martyn