Greg, I think it is probably best to think along the same lines as Practix. Arguably, that design is OK in the respect we are talking about MSDE.
Ie: Completed, Temporary, and Reference data. To read your mind and assume where you are going with this, We could have another database potentially, for each year that contains completed data being archived. This could reduce the size of the "Completed" database, so that it's size is managed over the years. A strategy such as this could extend the life of an application using MSDE or SQL 2005 Express. But I think most vendors set out to build a TreeHouse Greg, and they keep adding on little extensions over time as the Government and the GP's request things. Effectively giving us a patched up package that is very shaky, and dangerous, as this thread originally started out suggesting. Not many, and I have only found 1 at the moment as I haven't looked at all of them, started out building a warehouse with the flexibility to grow with the needs of a changing environment such as health. That product is Profile from Intrahealth. Technically, that product is a standout to any of the others I have seen todate. Your last couple of Questions, I'll respond by saying the application will manage the "Linking" of related data, between the tables in the different databases such as UR number as an identifier. They simply use a fully qualified Name to address data between different databases. Ie:linked_server.catalog.schema.object which means <ServerName>.<Database>.<Owner>.<Object> Merging them into 1 database ???? Again, the software vendor would have to have the forthought to build that into their applications. SQL server along with other highend Database Engines have the ability to spread "data", across different disks and so on, but I think the answer you're after Greg is can you manage that sort of management ??. No we can't. The Vendors would need to have the management tools written to do that usually. Regards Barry -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Twyford Sent: Thursday, 2 February 2006 12:34 PM To: General Practice Computing Group Talk Subject: Re: [GPCG_TALK] File repair utility in MD2 Barry Lollo wrote: > Greg, > > Practix might be a good example for you to look at then. > > They use the Default Instance (1 SQL server), but they have 3 > databases that they use. > > Mspdata - This stores the completed data - can get large > Msplocal - This is temporary data, such as appointments etc > - should be relatively small > Mspref - This is Data like Item Codes, Bank Details, and other Static > data. - will be small > > The application uses all 3 Databases which all have a 2 gig limit > giving them the ability to address 6 gig theoretically, getting around > the 2gig restriction. > > Clearer ?? Barry, Much. Its just that no one was saying this. I assume thenm there is some flexibility in how you could cut up an app such as MD. Results one database, Requests another. Letters another? Is it flexible enough to allow the operation of primary and secondary keys across the various databases? If so, you could reduce a 'database' to a single table? Thanks Greg -- Greg Twyford Information Management & Technology Program Officer Canterbury Division of General Practice E-mail: [EMAIL PROTECTED] Ph.: 02 9787 9033 Fax: 02 9787 9200 PRIVATE & CONFIDENTIAL *********************************************************************** The information contained in this e-mail and their attached files, including replies and forwarded copies, are confidential and intended solely for the addressee(s) and may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the intended recipient, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication or any action taken or omitted to be taken in reliance upon this message or its attachments is prohibited. All liability for viruses is excluded to the fullest extent permitted by law. *********************************************************************** _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
