Posted by panic attack on 08/04/06 08:17

hi again...
partitioning the table is one of the solvation but for our production
system unfortunately it is not proper for use. :((
cause we have lots of clients and if we partition the tables for our
each client there are gonna be enourmus number of tables, so it is not
possible to deal with those number of tables right now...

hence, we need to get the data at once, in one table.
perhaps we can union some columns into one column. but again there will
be some leck of use of the data while manipulating it.
as you can see it seems not good... :((

i hope that erland may advise another solvation about the problem.
or we may upgrade the database to sql server 2005 if it is gonna help
us getting the data into one table without any problems.

i really appreciated for your help.
thanks a lot.
best regards.

Tunc

NiTiN yazdi:
> panic attack wrote:
> > Erland Sommarskog wrote:
> > > panic attack (tunc.ovacik@gmail.com) writes:
>
> -- SNIP --
>
> > CREATE TABLE [nwind].[dbo].[DDD] (
> > [Col001] varchar (255) NULL,
>
> -- SNIP --
>
> > [Col543] varchar (255) NULL
> > )
>
> -- SNIP --
>
>
> Hi!
>
> I know I said earlier that you could use long data types, and the table
> you're trying to create is in accordance with my statement earlier.
> However, I should have added that each column stores a pointer in the
> row and the actual data is stored in a different location. If you add
> up the sizes of the pointers along with other row data they should be
> below the ~8K limit too. I guess I should be more accurate when I say
> something in future like those people who speak legal-ese. The DDL
> query was really funny to look at, and it's the first time I ever used
> the "read more" link on Google Groups.
>
> I would suggest that you partition your tables vertically so you have
> some of the columns in one table and the other columns in another table
> (...or perhaps more than 2 tables, depending on the sizes... I'm not
> really good at the math).
>
> N.I.T.I.N.
>
> PS: I hope I never have to deal with such a monstrosity - a table that
> has so many columns. I once had to deal with 36 columns and that was
> too much for me as a developer (that was before my days as a DBA). I
> split it up into 3 tables though people may say it is less efficient to
> have 3 queries instead of one (remember the days when people said you
> should use assembly language as the code is smaller & faster?).
>
> PPS: No offence to assembly language developers in the last 'PS'. I
> totally respect people who still use assembly, but for me it's just a
> little too much source code to think straight - I'd spend a whole hour
> doing something that I could do in 15 minutes with VB, Java or C# (when
> equipped with the right IDE, of course!).

[Back to original message]