I don't understand what you'd gain by splitting off tableA.  It seems to
me that it would only add confusion.

We have fairly large DBs running in MS-SQL2k.  For example, we have a
history of every WAP hit to a set of sites listed, which runs into
bazillions of records over the last couple of years.  We've not seen any
noticable performance hit because of it.

Also, what do you mean by "one set of data is oustside the domain of the
other set"?  After all, you've got a relationship between them built.

--Ben

Won Lee wrote:
> Any SQL server experts on the list?
>
> I'm curious what the best practice is in regards to the size of a DB.
> I have a two databases.  While one set of data is outside the domain of the
> other set, they are related by a single table.
> Is it better to just have two seperate DBs?  Simplest example would be this.
>
> TableA
> --------
> IDA
> IDB
> column1
> column2
>
> TableB
> ---------
> IDB
> column1
> column2
>
> TableC
> ---------
> IDC
> IDB
> column1
> column2
>
> TableA and TableB are joined on IDB and TableB and TableC are joined by IDB
> too.  TableC and TableA don't have any things in common except tableB.
> The real life problem I'm working on is this.  TableA is a table of client
> order information.  TableB is table of all stocks.  TableC is a table of
> historical price info for the stock for each day the markets are open.
>
> Seperate TableA into a seperate DB and put TableB and TableC in
> another?  Or put them all in the same DB even though any application that
> will make any calls to tableA will never call tableC and any application
> that makes calls to tableC will never call tableA? *I want to keep tableB
> and tableC together because I need these queries to run faster.
>
>
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]

Reply via email to