Currently I have a small business where I have a main product (written in PHP and MySql), several users, several companies, etc.

The software occupies around 20 tables in its operation. The problem is that I want to expand the business and create a different program, but I want to unify the data.

A new program (different function) will use about 30 tables, but in reality there is a "core" that are the same tables, let's say 10.

Here I have two options:

  • Create a larger database with 20 + 30 tables, (since some were repeated) = 40 tables.

  • Or create different and connected databases

    DB_core = 10 tables
    DB_1 = 10 tables
    DB_2 = 20 tables

Why using different databases?
I already want to develop this second software with a different team, but I don't want to give them access to some sensitive or valuable information, tables of people, companies, etc. This data will keep it in the "core" database and only in the production server.

From what I understand, users can be created with permissions by tables, but I feel that it is much easier to keep us in separate databases. Are there any significant performance implications? Is the most extensive programming worth it?

PD: Sometimes, I need the programmers team manage the production server.

  • 1
    I would say it's time to hire a DBA with modeling experience! Commented Mar 25, 2020 at 13:28

1 Answer 1


A logical separation by databases is a sensible move.

There is no performance impacts of this compared to table separation.

Programming becomes referencing by database.table rather than just table.

Eventually you'll need to raise the table cache sizes in your server.

Be careful with permissions and provide guidance for your programmers. Too often they open up permissions to try to make things work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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