Search code examples
mysqldatabase-designparadigms

MySQL: Many joins and relations on the same table (theoretical question)


This is a more theoretical question, not a specific scenario:

Let's assume, we have a simplified table scheme like this:

alt text

items contains some basic data, item_data additional properties for each item an rel_items sets a tree relationship between the different items. There are different types of items (represented by the field items.item_type) which have different fields stored in item_data, for example: dog, cat, mouse.

If we have some bigger queries with some joins and conjunctions (stuff like getting items with their parent items having some conditions with other items and so on), could this become a performance issue compared to splitting all different types of items into separate tables (dog, cat, mouse) and not merging them into a single one?

If we keep it all in one basic item table, does creating views (dog, cat, mouse) impact performance somehow?

edit (as commented below): I thought of "species", "house-pets" and so on as item_types. Each type has different properties. The intention of using a basic item table and the item_data table is to have a basic "object" and attaching as many properties to them as necessary without having to modify the database scheme. For example, I don't know how many animals there will be in the application and what properties they have, so I thought of a database scheme that doesn't need to be alterted each time the user creates a new animal.


Solution

  • If we have some bigger queries with some joins ..., could this become a performance issue compared to splitting all different types of items into separate tables (dog, cat, mouse) and not merging them into a single one?

    No.

    If we keep it all in one basic item table, does creating views (dog, cat, mouse) impact performance somehow?

    No.

    Separate tables means they're fundamentally different things -- different attributes or different operations (or both are different)

    Same table means they're fundamentally the same things -- same attributes and same operations.

    Performance is not the first consideration.

    Meaning is the first consideration.

    After you sort out what these things mean, and what the real functional dependencies among the items are, then you can consider join performance.

    "Dog, cat, mouse" are all mammals. One table.

    "Dog, cat, mouse" are two carnivores and one omnivore. Two tables.

    "Dog, cat, mouse" are two conventional house-pets and one conventional pest. Two tables.

    "Dog, cat, mouse" are one cool animal and two nasty animals. Two tables.

    "Dog, cat, mouse" are three separate species. Three tables.

    It's about the meaning.