Re: Help, my developers are killing me with varchar2(4000)
From: Noons <wizofoz2k_at_yahoo.com.au>
Date: Tue, 12 Aug 2008 21:21:35 +1000
Message-ID: <g7rrni$gjr$1@registered.motzarella.org>
> Theere are also issues of scalability, both in data size and number of
> users. The world gets a lot more complex when your database leaves
> your test environment, where it had a few dozen rows per table and
> three or four users, and suddenly has a few million rows and a few
> hundred users. In such circumstances, I have seen few implementations
> of the "big bucket" data model survive for long. Most fail pretty
> quickly, because you need to do everything right if you want to scale
> up substantially.
>
Date: Tue, 12 Aug 2008 21:21:35 +1000
Message-ID: <g7rrni$gjr$1@registered.motzarella.org>
phil_herring_at_yahoo.com.au wrote,on my timestamp of 12/08/2008 1:38 PM:
>big snip
> Theere are also issues of scalability, both in data size and number of
> users. The world gets a lot more complex when your database leaves
> your test environment, where it had a few dozen rows per table and
> three or four users, and suddenly has a few million rows and a few
> hundred users. In such circumstances, I have seen few implementations
> of the "big bucket" data model survive for long. Most fail pretty
> quickly, because you need to do everything right if you want to scale
> up substantially.
>
very true. To use a db as a bit bucket is the negation of the very idea of building on previous work. Which is a characteristic of some current deranged development methodologies: nothing like re-inventing the wheel at every corner to guarantee a continuous stream of income, ain't it?
Fact is: dbs have inbuilt mechanisms for type diversity and coherence as well as scalability. Already debugged, optimized and ready to work for any project, not just the flavour-de-jour. To ignore such a resource in the name of vague design notions never proven in any successful delivery borders on criminal... Received on Tue Aug 12 2008 - 06:21:35 CDT