Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Steve2106
Posting Yak Master
183 Posts |
 Posted - 2012-05-24 : 14:53:03
|
| Hi There,I have been having a heated debate with one of my friends and thought I would ask for your thoughts.My friend is a dotnet developer and uses MS Sql as his database. The company he works for develope a range of products which can all work together or seperately.My argument is that each product should have it's own database.His argument is that it should be 1 massive database holding all the tables and stored procedures for all the products because it's easier to get it all working if the client buys additional products.So if a client only purchases 1 application they get a database containing the relevant tables etc for that product but also all the tables etc for the other 5 products.Surley this is wrong.Your wisdom is welcome.Thanks for your input.All the best,Steve |
|
|
yosiasz
Master Smack Fu Yak Hacker
1635 Posts |
Posted - 2012-05-24 : 15:01:23
|
| it depends always depends1. Un-friend him. Do not associate with dotnet developers :D2. he should stick to what he knows best dotnet development :D3. hear him out and see what his reason is to bundle it as one package. Since you have not shared with us his reason for doing so hard to give an opinion4. I can see why they want to bundle it. Let's say user wants to purchase the next product there won't be any integration issues, seamless 5. I always say hear developers out. They might be able to give you a new insightwhat size are we talking about here when you say massive<><><><><><><><><><><><><><><><><>If you don't have the passion to help people, you have no passion |
 |
|
|
Vinnie881
Master Smack Fu Yak Hacker
1231 Posts |
Posted - 2012-05-24 : 15:21:11
|
There is not a universal answer, but a general rule of thumb for me that I use is I normally use a separate database for each APPLICATION of data. .NET programming is a very different mindset to database development, but that does not mean they can not also be a database developer. I've been in heated debates too when I was a little younger and a lot of the debates turned into wanting to be correct so much, that often both parties put so much emphases on supporting their claims to make themselves right when it is rarely necessary.A good database is organized, well structured data, efficient queries, and does not pigeon hole you for future expansion. How each person achieves that is not the same, but there are good general rules to follow.Sounds like something not worth being in a heated debate about and yosiasz gave very good advice of there is always someone that knows something you do not, so be open to hearing their reasons. A better approach is to not tell people they are incorrect, but rather suggest a possible alternative that may help out. This way people don't tend to need to defend themselves or what they did.[edit]So there is less confusion: My reference to the term "Application", IS referring to each different software application and it's data, not each different use for data. i.e. 1. Software application holds data for a Widget processing plant 2. Software application holds data for a coffee bean processing plantI would use a separate database for each above application, even if they had certain similarities. "ENTERPRISE" is a better term and more clear![/edit]
Success is 10% Intelligence, 70% Determination, and 22% Stupidity.\_/ _/ _/\_/ _/\_/ _/ _/- 881 |
|
|
|
LoztInSpace
Aged Yak Warrior
940 Posts |
Posted - 2012-05-25 : 03:39:20
|
| My 2c:Generally I'd advocate as few databases as you can. Data belongs to "the Enterprise" with liitle, if any, belonging to a specific application and only that application.If the suite of apps your friend sells are related then I'd say he's doing the right thing. Do you really want to maintain and synchronyse 5 copies of your customers because you've bought 5 modules? No.If you've ever worked in a web shop, you'll have soon discovered that disjointed data is a pain. You call one web service to get one set of data, another for another and join it up yourself. Then you find there's no integrity so the error handling multiplies. Next the web servers run out of memory or you start having to do paging because some dumb web service is sucking the entire database into RAM (in XML!). Well the same thing happens when you split databases and the way around it is to use database links. By which time you realise that life would be better in one large database.Even if they are unrelated, I'd still look long and hard at keeping it all together. Eventually you find yourself bringing data together in ways you didn't anticipate.Same arguments for security, backups, infrastructure etc etc. Do it as few times as you can.You pay a lot for a database - use the features. Looking after data is one of those features!In an ideal world, the only way I'd split databases is something like the following:1) "Enterprise data". This is the proper stuff - clients, orders, stock levels etc. This is what your business *is*.2) "Fluff data" - Presentation stuff such as web content, CSS, text strings, translations, images, logos etc. The "lipstick for the pig" that is your real data.3) usernames, preferences, user settings, configurations etc for an app or sets of apps.4) Correspondence (and even then I'm not 100% sure this doesn't count as 1) .5) Operational stuff (HR system, accountancy, timesheets, payroll)Your friend's domain may vary this list of course. I get the feeling he'd be all in 1 for some reason. |
|
|
|
|
|
|
|
|
Seperate databases or all in one