Are the posted questions getting worse?

  • We are aware of the presence of forbidden code. We are watching.

  • Okay threadiatics, if you have choice between putting data for multiple applications in 1 database because there is some common data or application specific databases?

  • OK, umm.... It Depends?

    on business needs,

    on security boundaries,

    on data sensitivity(see above).

    To help us help you read this[/url]For better help with performance problems please read this[/url]

  • How big, how much common data?

    If there's any chance for one causing issues on the server, especially with heavy tempdb usage, and might require it's own server, I'd say separate databases. Hard to separate later.

  • If one application can change the common data, and, the other need to see these changes, then I would put the common data in a common database, to avoid having to sync data.



    Alvin Ramard
    Memphis PASS Chapter[/url]

    All my SSC forum answers come with a money back guarantee. If you didn't like the answer then I'll gladly refund what you paid for it.

    For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]

  • It depends. But I think that this would be a good question to put over on askSSC.

    __________________________________________________

    Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
    Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills

  • Additionally, will this common data always be common, how hard will it be to keep in sync if you separate them? Are we just talking user information, company information etc or is it more than that?

    To help us help you read this[/url]For better help with performance problems please read this[/url]

  • Jack Corbett (10/15/2009)


    Okay threadiatics, if you have choice between putting data for multiple applications in 1 database because there is some common data or application specific databases?

    Yes.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • I would also say Yes provided you have a way of identifying what application changed what data and if there is a need to have reports based on all the applications.

    -Roy

  • Any data that is definetly not common I would be tempted to put in application specific databases. This would make it easier to migrate application to different servers in the future.



    Alvin Ramard
    Memphis PASS Chapter[/url]

    All my SSC forum answers come with a money back guarantee. If you didn't like the answer then I'll gladly refund what you paid for it.

    For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]

  • Not big. We are talking, biggest non-audit table is less than 30K rows with maybe few hundred to a thousand added a year.

    My biggest issue is that one project is moving very slowly and the other project is much simpler and could be completed earlier. Providing users with a system where there is not a system at this point.

  • Jack Corbett (10/15/2009)


    Okay threadiatics, if you have choice between putting data for multiple applications in 1 database because there is some common data or application specific databases?

    Unless there's just oodles of common data, I'd put 'em in seperate db's. That's a reversal of a stand I took up until about 5 years ago for anyone that's monitoring.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Bob, good idea and will do.

    Just for the record I'm a separate 'em guy and I'm the roadblock, or as I like to say the voice of reason.

  • Jack Corbett (10/15/2009)


    Not big. We are talking, biggest non-audit table is less than 30K rows with maybe few hundred to a thousand added a year.

    My biggest issue is that one project is moving very slowly and the other project is much simpler and could be completed earlier. Providing users with a system where there is not a system at this point.

    With this information, I'd suggest separate databases. That will allow you to separate your dev/test/prod instances/databases to allow development at different rates. Also, what happens when the devs from one group change something int he common data that breaks the other app? Seems like that might be more likely to happen than not.

    What happens if the slow moving project dies? Then you waited on them for nothing.

    I'd say get em something that works, and then if the slow moving project finally comes online, deal with synching the data later.

    -Luke.

    To help us help you read this[/url]For better help with performance problems please read this[/url]

  • Jack Corbett (10/15/2009)


    Bob, good idea and will do.

    Just for the record I'm a separate 'em guy and I'm the roadblock, or as I like to say the voice of reason.

    I do not know what your business needs are or your business rules are. But just to be devils advocate, if both the applications need to update and read the same set of data, I would prefer to have it in one DB. Then I do not have to bother with how the data that is updated in one DB gets propagated to another DB.I do not have to think of Replication or additional servers/Instances/Users. Users sharing multiple Databases.

    I am the devil here....:hehe:

    -Roy

Viewing 15 posts - 8,611 through 8,625 (of 66,712 total)

You must be logged in to reply to this topic. Login to reply