Share your stories + is it bad to have multiple dbs?
2008-08-05 17:47
489 查看
来源:http://www.imcoder.org/architecture/187115.htm
Q:
I am a young and ambitious developer building a large web app as a personal project/site and I am sure that there are plenty of experienced web developers on here.
Having read this section very often, I have seen some good advice provided by experienced individuals (professionals). Perhaps some of you can share your experiences and lessons learnt on delivering large web apps? Would make for a good thread if this can take off. :)
Also, what I was wondering was, would it be a good idea to have seperatedatabases for each of my web app's "systems"? I.E. the ad managementservice has its own table, as does the newsletter system.
A:
I believe if the tables were not related to each other then we can easily keep some data in another database. Like for example if we make a website and also plan to log Ipaddress etc of visitors. Now the logging tables can easily be kept in another database. This helps keep the size of database under control and also make thing a little faster in execution since only database is not under attack for all the queries.
A:
This helps keep the size of database under control and also make thing a little faster in execution since only database is not under attack for all the queries.
Yes, BUT...
If your database is under attack from all the queries i suggest better programming or not running it on a PDA: Seriously, if you have that on a modern computer or a shared host that possibly is a pretty irrelevant point for anything but a LARGE database, and output caching and smart programming can take out even more pressure.
The negatives are hugh:
It means a lot more open connections.
It possibly means getting distributed transactions into place, which are a LOT more heavy in terms of resources used than in database transactions.
It makes backup/restore of a defined moment in time pretty much something to write a thesis on, not something you just do.
I would generally say, keep to one database for one system. If necessary use schemas to isolate tables, or use prefixes. Use a central database if necessary to orchestrate systems, like sharepoint does: one for management, one for every content store. Or like MS CRM 4.0 does: one for management, one for every "entity" that runs a CRM instance.
But to split logging, newsletter etc. into different databases is just not necessary.
A:
I totally agree here, you will find that generally development and management are much simpler when using the minimum number of databases. There does come a point of diminishing returns however when the sheer number of tables/views/stored procedures in your database makes management a nightmare.
In general if find that databases tend to seperate themselves quite logically anyway. For example we have one DB for all our intranet site stuff (news alerts, page contents, adverts, user info) and then another one for our contract support system. The CS system and the intranet DB very rarely need to interact so its easier keeping them seperate, especially if we will ever need to move the CS system elsewhere (where the intranet may not be present), on the other hand if we had split the Intranet DB into smaller sections we would have ended up constantly opening new DB connections and wasting resources.
A:
I reckon it would be best to keep to one database, because most of these "systems" would need to interact with the user tables.
So far, I have designed one schema which has the user registration tables, and all the table for the prime user functionality of the system. The frontend extra systems like newsletter would need to relate to the user tables so I guess that gives me my answer.
Would partitioning be a useful issue to think about?
BTW this forum and this section in particular is great, because a lot of the stuff I've picked up from here and learnt I would never learn from reading books but only from years of experience (need a few more yrs of that).
A:
To be honest I tend to think of user data as immune from this kind of discussion as it will be needed from almost every app you build, its that special case.
At the risk of taking this off topic, my thoughts on how user management should be handled in large intranet(mainly) based situations. This isn't how we operate, but if I was to start over I'd think carefully about these topics.
User data should be in either its own DB or part of a phonebook/contacts application.
I would have a standard interface for a User and implement a provider model. This way you can move your applications into a new environment and link into whatever user system is in place there. You could be grabbing the User information via webservices, from AD, out of a database, whatever.
The above providers should implement some form of caching to ensure that we aren't making two different data connections (at least) with every page request
Role information should be managed by the individual applications in whatever way they need.
I'm sure there is other data which should be handled like this, although I can't think of any at the moment.
A:
There is a lot of talk about seperation of concerns and how it helps with development and is a good habit to practise.
That's why I raised this thread. At the moment my database is diluted with multiple concerns. With the scale of the schema, the design is fraught with danger.
However, with user data in its own db, I would then have to be opening connections to multiple databases in the front end (ie a user would be using functionality in two seperate databases). This does seem like a waste of resources and a nightmare for me, the developer. However, seperate databases would mean cleaner database schemas which are easier to profile and diagnose.
I will have to have multiple databases as there are units of business processes which are too distinct ie logging and core functionality. However, the trick must be to not be using more than one database in the process of achieving one objective.
Q:
I am a young and ambitious developer building a large web app as a personal project/site and I am sure that there are plenty of experienced web developers on here.
Having read this section very often, I have seen some good advice provided by experienced individuals (professionals). Perhaps some of you can share your experiences and lessons learnt on delivering large web apps? Would make for a good thread if this can take off. :)
Also, what I was wondering was, would it be a good idea to have seperatedatabases for each of my web app's "systems"? I.E. the ad managementservice has its own table, as does the newsletter system.
A:
I believe if the tables were not related to each other then we can easily keep some data in another database. Like for example if we make a website and also plan to log Ipaddress etc of visitors. Now the logging tables can easily be kept in another database. This helps keep the size of database under control and also make thing a little faster in execution since only database is not under attack for all the queries.
A:
This helps keep the size of database under control and also make thing a little faster in execution since only database is not under attack for all the queries.
Yes, BUT...
If your database is under attack from all the queries i suggest better programming or not running it on a PDA: Seriously, if you have that on a modern computer or a shared host that possibly is a pretty irrelevant point for anything but a LARGE database, and output caching and smart programming can take out even more pressure.
The negatives are hugh:
It means a lot more open connections.
It possibly means getting distributed transactions into place, which are a LOT more heavy in terms of resources used than in database transactions.
It makes backup/restore of a defined moment in time pretty much something to write a thesis on, not something you just do.
I would generally say, keep to one database for one system. If necessary use schemas to isolate tables, or use prefixes. Use a central database if necessary to orchestrate systems, like sharepoint does: one for management, one for every content store. Or like MS CRM 4.0 does: one for management, one for every "entity" that runs a CRM instance.
But to split logging, newsletter etc. into different databases is just not necessary.
A:
I totally agree here, you will find that generally development and management are much simpler when using the minimum number of databases. There does come a point of diminishing returns however when the sheer number of tables/views/stored procedures in your database makes management a nightmare.
In general if find that databases tend to seperate themselves quite logically anyway. For example we have one DB for all our intranet site stuff (news alerts, page contents, adverts, user info) and then another one for our contract support system. The CS system and the intranet DB very rarely need to interact so its easier keeping them seperate, especially if we will ever need to move the CS system elsewhere (where the intranet may not be present), on the other hand if we had split the Intranet DB into smaller sections we would have ended up constantly opening new DB connections and wasting resources.
A:
I reckon it would be best to keep to one database, because most of these "systems" would need to interact with the user tables.
So far, I have designed one schema which has the user registration tables, and all the table for the prime user functionality of the system. The frontend extra systems like newsletter would need to relate to the user tables so I guess that gives me my answer.
Would partitioning be a useful issue to think about?
BTW this forum and this section in particular is great, because a lot of the stuff I've picked up from here and learnt I would never learn from reading books but only from years of experience (need a few more yrs of that).
A:
To be honest I tend to think of user data as immune from this kind of discussion as it will be needed from almost every app you build, its that special case.
At the risk of taking this off topic, my thoughts on how user management should be handled in large intranet(mainly) based situations. This isn't how we operate, but if I was to start over I'd think carefully about these topics.
User data should be in either its own DB or part of a phonebook/contacts application.
I would have a standard interface for a User and implement a provider model. This way you can move your applications into a new environment and link into whatever user system is in place there. You could be grabbing the User information via webservices, from AD, out of a database, whatever.
The above providers should implement some form of caching to ensure that we aren't making two different data connections (at least) with every page request
Role information should be managed by the individual applications in whatever way they need.
I'm sure there is other data which should be handled like this, although I can't think of any at the moment.
A:
There is a lot of talk about seperation of concerns and how it helps with development and is a good habit to practise.
That's why I raised this thread. At the moment my database is diluted with multiple concerns. With the scale of the schema, the design is fraught with danger.
However, with user data in its own db, I would then have to be opening connections to multiple databases in the front end (ie a user would be using functionality in two seperate databases). This does seem like a waste of resources and a nightmare for me, the developer. However, seperate databases would mean cleaner database schemas which are easier to profile and diagnose.
I will have to have multiple databases as there are units of business processes which are too distinct ie logging and core functionality. However, the trick must be to not be using more than one database in the process of achieving one objective.
相关文章推荐
- this path is in ef to find it,if i have enough time i will to visite this website again
- Internet Information Services is not installed. You must have Internet Information Services installed in order to use the SharePoint Products and Technologies Configuration Wizard
- "I ask you, have you ever known what it is to be an orphan?"
- myeclipse 报错:Multiple operations have reported errors.Select an error to view its details.
- 解决 The 'InnoDB' feature is disabled; you need MySQL built with 'InnoDB' to have it working
- mac上的xampp出现Access forbidden! You don’t have permission to access the requested object. It is either
- 【原】The 'InnoDB' feature is disabled; you need MySQL built with 'InnoDB' to have it working
- It Takes Two to Tango (myself, and your unprotected file share)
- 解决 The 'InnoDB' feature is disabled; you need MySQL built with 'InnoDB' to have it working
- Activity has leaked window that was originally added -界面退出时未关闭对话框异常 android.view.WindowManager$BadTokenException: Unable to add window -- token null is not valid; is your activity running? -
- 问题-XE8报Object factory for class{xx-xx-xx-xx-xx} is missing. To register it, you can drop component[TFDGUIxWaitCursor] into your project.
- Why SHRINKFILE is a very bad thing, and what to do about it.
- 在myeclipse中保存时总是弹出错误提示框,错误信息: Multiple operations have reported errors Select an error to view its d
- view.WindowManager$BadTokenException: Unable to add window…is not valid; is your activity running?
- appears to have started a thread named [startQuertz_xxx] but has failed to stop it. This is very...
- AnyConnect cannot confirm it is connected to your secure gateway.
- 警告: The web application [ROOT] appears to have started a thread named [Thread-48] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
- The 'InnoDB' feature is disabled; you need MySQL built with 'InnoDB' to have it working处理方法
- If you have multiple web application run how to determin which is yours when you debug using visual studio 2008?
- USB ZTE Modem will crash your Snow Leopard. Here is how to fix it.(转)