0

I read on a forum about the use of database isolated environments are neccessary for any large project that handles "big" data. For instance I will be using the following table for ALL blogs:

projectname_blog_blogposts

We all know that the table will be very big. Probably hard to maintain, maybe awful situation if the table is corrupt or something like that. I don't know, I don't have any experience to confirm such a statement.

So instead of doing that. Is this approach better:

projectname_blog_1_blogposts
projectname_blog_2_blogposts
projectname_blog_3_blogposts

And then split them up like this:

DATABASE01

projectname_blog_1_blogposts

DATABASE02

projectname_blog_2_blogposts

DATABASE03

projectname_blog_3_blogposts

Sorry if the question is fuzzy. But I do hope you guys understand me.

Where can I read more about this so I can make a good choice?

  • 1
    "Large" = what? If you are talking about gigabytes, that is not "large". Terabytes is "large". "Multi-tenancy" involved extra hassles, extra overhead, etc.; don't do it for "small" projects. – Rick James Jan 13 '16 at 3:58
0

the problem you are facing can be likened to the problem of multitenancy as you are talking about multiple applications (multiple blog) and one or more tables, schemas, databases, instances. A good starting point can be the following article from MSDN: Multi-Tenant Data Architecture. The article is focused on Microsoft SQL Server but it can be easily generalized.

Regards Giovanni

| improve this answer | |
  • That was exactly what I was looking for. Thank you Giovanni! – Y7da Jan 12 '16 at 14:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.