October 15, 2009 at 1:18 pm
We are aware of the presence of forbidden code. We are watching.
October 15, 2009 at 1:21 pm
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?
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
October 15, 2009 at 1:26 pm
October 15, 2009 at 1:27 pm
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.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
October 15, 2009 at 1:29 pm
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.
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]
October 15, 2009 at 1:31 pm
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
October 15, 2009 at 1:32 pm
October 15, 2009 at 1:33 pm
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
October 15, 2009 at 1:35 pm
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
October 15, 2009 at 1:36 pm
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.
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]
October 15, 2009 at 1:37 pm
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
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
October 15, 2009 at 1:37 pm
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 RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software
October 15, 2009 at 1:40 pm
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
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
October 15, 2009 at 1:43 pm
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.
October 15, 2009 at 1:47 pm
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,000 total)
You must be logged in to reply to this topic. Login to reply