Re: Isolating Customer Data

Yes, my us eof the word 'physically' was incorrect. Having the data in
seperate DB's is fine.

Short of having Dynamic Query strings generated in the code *shudder*. I
think the solution is going to have to be to replicate the schema, SP's and
views across each clietns DB.

Would you agree?

TIA

MattC
"Andrew J. Kelly" <sqlmvpnooospam@xxxxxxxxxxxx> wrote in message
news:eAL$AkEGGHA.2708@xxxxxxxxxxxxxxxxxxxxxxx
> That is one of the great requests on these newsgroups. But in this case
> you really can't have your cake and eat it too<g>. Most sp's need to be
> inside the individual user db itself to get the correct results. How many
> db's are you talking about? If you have proper procedures in place to
> ensure you do the right things when distributing or updating sp's it's
> really not that difficult. There are even some third part tools out there
> that make it relatively easy to store the object code in a central
> location and then distribute the changes. But one question I have for you.
> What exactly do you mean by "Physically separate"? To me that would
> entail one db per physical disk array. Having two db's on one disk does
> not "Physically" separate the data.
>
> --
> Andrew J. Kelly SQL MVP
>
>
> "MattC" <m@xxxxx> wrote in message
> news:OV3IoWDGGHA.3176@xxxxxxxxxxxxxxxxxxxxxxx
>> Hi,
>>
>> Wondered if anyone had any best practice or experience in isolating
>> customer data from each other. We have a system that will need to store
>> a customers data and from that provide calculations on that.
>>
>> However, ther is a requirement that the data for each customer be kept
>> physically separate. My initial thought was to create a central database
>> for the application, this would store information about each customer
>> such as the name of the database and possbily the server where their data
>> resides.
>>
>> My problem comes with the storeprocedure layer. I have no problem
>> replicating the schema for each customers but I would rather have only
>> one place where the stored procs are located. Every time there is an
>> update to be made I don't want to have to update the stored proc on each
>> database.
>>
>> Any advice or infomation would be greatly appreciated.
>>
>> MattC
>>
>
>


.

Relevant Pages

  • storage of arbitrary attributes and their names
    ... We didn't want to encode these directly into the database ... schema, so we were looking to use a table to store the name/value ... the customer. ... made sense to have a separate table to store the names and refer to ...
    (microsoft.public.sqlserver)
  • Re: Isolating Customer Data
    ... That is usually the easiest way to manage it when you need to have separate ... >>> customer data from each other. ... We have a system that will need to store ... >>> database for the application, this would store information about each ...
    (microsoft.public.sqlserver.security)
  • Re: Isolating Customer Data
    ... relatively easy to store the object code in a central location and then ... you mean by "Physically separate"? ... > customer data from each other. ... My initial thought was to create a central database ...
    (microsoft.public.sqlserver.security)
  • Re: Returning stuff to Costco or Sams
    ... database, which gives them a yes/no authorisation. ... as long as the customer is notified at the time ... or the store would likely have a tough time enforcing it. ...
    (misc.consumers)
  • Re: report on customer rage
    ... >> verbatim FYI for those with customer service nightmares (and I ... >> As shoppers head into the holiday shopping season, ... >> A shopper at a Michael's craft store is behind a man doing a price ... who rebuilt yur kombi for ya? ...
    (alt.fashion)