From: Ellen K. 

On Tue, 23 Mar 2004 22:07:41 +0200, "Antti Kurenniemi"
 wrote in message
:

>"Ellen K." 
wrote in message
>news:cjr060pkdaa069f4li1be84ltu1qm0l8su{at}4ax.com...
>> Are these four tables often joined in queries?
>
>Eh, well how should I say this... the current system doesn't really have
>queries at all, so no, not really, but they would need to be.
>
>
>>  If so then putting them on different disks is a good idea.
>> But you are going to need a LOT of disks then because you
>> still need redundancy and also putting the transaction log on
>> its own disk is probably more important.
>
>Yeppers. I don't think I'd have everything on it's own disk, but at least it
>would give me possibilities to test and search for a good balance.
>
>
>> How many disks are you gonna have?
>
>I have 6 now and an empty 6 disk case so 12 in total. 1 for the system, 1
>hotswap, so 10 to use for whatever I want basically. Should be a lot of fun
>
>
Cool, this should give you enough room to do stuff!   You should use 2
for the transaction log, that leaves 8... probably 2 3-disk RAID5 arrays
for the data and clustered indexes (each clustered index lives in the same
data file as the table it belongs to), which means you can split up your 4
tables however works best, and another mirrored pair for the nonclustered
indexes, although this will be more space than you need... you could make
the last mirrored pair have two logical drives and use one for the
nonclustered indexes and the other one for the swap file.

>
>> You can certainly add indexes once you move the back end to
>> SQL Server.
>
>Yes, that's true. I'm very excited about this possibility, because it would
>really make a huge difference in what we can do compared to now. Our whole
>operation is run one this system, and it works pretty well in all other ways
>except that reporting is near inpossible, which is quite a big problem. I
>would just love to be able to use proper reporting tools.
>
>
>> You could also add constraints to handle the data validation
>> that apparently isn't being handled in the front end, but this
>> can be a double-edged sword because it means the transaction
>> gets sent to the database and then if it's not acceptable an
>> error message is returned, i.e. you have more network traffic.
>
>I don't think I would do that, I'm much too scared of how the current system
>would handle errors like that. It's a real weird system.

Do you have the source code for it?
>
>
>Antti Kurenniemi
>

--- BBBS/NT v4.01 Flag-5