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