On Wed, Feb 17, 2010 at 5:38 PM, Jeff Johnson <[email protected]> wrote: > Looking for opinions here. Most of my customers have several sites. > With VFP I always put different sites in different folders so each site > has identical databases. When considering SQL Server or PostGreSQL > multiple databases seems cumbersome. The other option is to have one > database with one set of tables and have a site field. The problem with > this approach is that there is a chance that a mistake could make one > site's data available to another site. There is a lot of overhead for > printing reports and accessing data to keep thing separate. > > Can anyone conger up pros and cons for the two approaches? ------------------------
Separate dbs are not a problem. Getting tools to help you keep everything in sync or to identify differences are great from RedGate in SQL Server. What does your contract say about data storage? Do you have to amend that as well? If you were going to make a whole new db design then I would suggest a single db, just like a bank. You would have to re-define the app code to only pull the customer data. When on SQL or Postgres your index will have to be rock on for real success in this. <major point of your first performance problem> Other issues are security that you have to focus on. Are the dbs going to be held at customer site or on yours? -- Stephen Russell Sr. Production Systems Programmer CIMSgts 901.246-0159 cell _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
