[dba-SQLServer] Managing orders database

JWColby jwcolby at colbyconsulting.com
Thu Apr 19 17:22:53 CDT 2007


Long term that is actually a much better solution.  

There is ATM a set of a few tables in one database.  As I take orders
(counts) I build the sets of views that implement them, but the views
reference data (currently) out in another database where the actual data is
stored.

Actually it is more than a where clause though.  It typically takes anywhere
from one to 4 joins, sometimes outer joins, then pulling where fields and
counts.  Thus I tend to use base views and views joined to views, with those
counting and filtering.  I do like the concept of storing SQL in a table,
particularly since I could then have a real order database with an order
table.


John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of David Lewis
Sent: Thursday, April 19, 2007 2:42 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Managing orders database

John:  Interesting way of handling it.  It sounds as if all the data is in
one database, and you create new db's that are subsets of that data.
If that is the case, maybe you could have achieved your goal of easy
maintenance by creating a table structure for clients, queries, and where
clauses.  You could save the where clauses in a child table, and run them,
refine (ie add a record with a new where clause), etc. That way you would
have one db with tables with the data, and a few small tables recording the
queries.  Just a thought.  Probably I don't have all the details of the
project, though.  D

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com




More information about the dba-SQLServer mailing list