|
|
Posted by John Bell on 09/09/05 10:47
Hi
As you seem to have reached the limits of acceptability with your current
design, then maybe it is time to have a re-think and implement a better
structure. It sounds like this may have come from a flat file based system
and that is the history that is dragging you down! Migrating to separate
columns may not mean a single table. You can ease the backward compatibility
by creating a view to re-create the way the old table presented data, this
may mean that you don't have to change everything at once, although I would
make sure everything that inserts/updates the data is in the first tranche.
John
"Matik" <marzec@sauron.xo.pl> wrote in message
news:1126230904.603430.325640@o13g2000cwo.googlegroups.com...
> Hello 2 all,
>
> Thank You for response. Hugo, additional explenation: I posted just a
> part of view acctualy, in normal, it uses at the end pre defined order
> by. To use order by in a view, you need to specify a top :(
>
> John: I was wondering also ... but the explenation was easy: because of
> historical reasons ;) For me it is also more or less obvious, that
> storing data in separate collumns (specialy by long strings, and lot's
> of data) is much more efficiency, that concentrated (specialy by this
> scans).
>
> You're right, that I do not expect so much rows in my table, I don't
> acctualy know, why they integrated this collumn, but I need to keep it
> (i think, they are using it for replication).
>
> Primary key is set up on CID collumn (is not clustered with fill factor
> on 90%). I dont know why the script didn't included the statement :(
>
> I think, your idea is great, I was thinking acctualy exactly in this
> way, I just need to be sure, from someone with expirience.
>
> Thank You very much
>
> Mateusz
>
Navigation:
[Reply to this message]
|