Home/ Questions/Q 7403757
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T05:09:24+00:00

I have a simple design for DB used by SQL: Table1 – recipeTable key,

  • 0

I have a simple design for DB used by SQL:

Table1 - recipeTable key, value1..N, recipeId
Table2 - recipeInstructions key, instId, text, reciepIdFK (each instruction has entry)
Table3 - recpeIngredients key, ingId, text, recipeIdFK (each ingredient has an entry)

The question is – for doing queries etc on the DB (with joining info from all 3 tables), when will the tables size be a problem (e.g. search will take too much time).

Shoudl I do some clusturing – like table for ids 1..10000 etc.. – or the SQL does it in its own way?

The table size can get up to 100,000 and even more.

Yoav

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Firstly, I think you may be missing a table for “ingredients”. 

    Recipe
-------
RecipeID PK
Title
...

RecipeInstruction
------
RecipeInstructionID PK
RecipeID FK
sequence
description

Ingredient
---------
IngredientID
Name
....

RecipeIngredient
------------
RecipeID FK
IngredientID FK
quantity

    Secondly, the best way to work on scalability questions is to try them out. Design your database, populate with test data (I’ve used DBMonster in the past), and then work on the queries you need to support. Go for perhaps twice as much data as you think you’ll ever generate in real life. The fact you’re using a DAL doesn’t matter all that much – the DAL just generates the queries for you, and if you get the basics right, you can tune that in the future.

    For your app, I’m guessing you’ll want to run queries like:

    • get all recipes with ingredient x
    • get all recipes in category x
    • get all recipes without ingredient x
    • get all recipes that take less than x minutes
    • get all recipes with ingredients (x, y, z)
    • get all recipes with difficulty x

    As well as combinations of the above. See if your queries work; if they do, leave well enough alone. Seriously, don’t “optimize” just in case. If the queries don’t work, tune them. Learn about indexing, and free text search.

    If that doesn’t work, think about buying bigger hardware. In the long run, it’s cheaper than exotic design solutions (like “one table for records up to 10000” – just imagine the data access logic for that…).

    In very general terms, if your queries can use an index, they’ll perform perfectly adequately joining several tables across many millions or records on modern affordable hardware. It’s safe to assume that all your “ID” columns will be indexed, and that searching by index will be fast.

    What’s likely to be slow is searching on text values if you have to support wildcards (e.g “where ingredient like ‘%banana%’). That’s where I’d put my energy – MySQL has support for free text searching, which is pretty quick.

    • 0