LINUX.ORG.RU

История изменений

Исправление alex_the_v, (текущая версия) :

Насколько я знаю, соединение - тяжелая операция

Месье был покусан MySQL 3.3?

Когда проектируют схему, то исходят из третьей нормальной формы. Потом (я подчеркиваю - потом, не сразу) участки, на которых возникают серьезные нерешаемые (я подчеркиваю - серьезные и нерешаемые) проблемы с производительностью, денормализуют.

В твоем случае транзакционная таблица только одна - это ORDERS. Если все правильно проиндексировано и оптимизатор в базе не полный лох (а он даже в мусколе не лох), то все у тебя будет ок. Если таки лох - похинтуй запросы руками, хотя я последний хинт писал еще для девятого Оракла, начиная с десятки CBO сам нормально допетривает, если ты запросы руками пишешь, конечно, а не жопой.

Если у тебя заказов десятки миллионов в неделю (в чем я лично сомневаюсь), то можешь подумать о разных способах оптимизации, например о секционировании этой таблицы.

NoSQL твою проблему не решит: проблема, скорее всего, у тебя в голове (если у тебя не десятки миллионов заказов в неделю).

Не выдумывай проблемы там, где их нет.

Исправление alex_the_v, :

Насколько я знаю, соединение - тяжелая операция

Месье был покусан MySQL 3.3?

Когда проектируют схему, то исходят из третьей нормальной формы. Потом (я подчеркиваю - потом, не сразу) участки, на которых возникают серьезные нерешаемые (я подчеркиваю - серьезные и нерешаемые) проблемы с производительностью, денормализуют.

В твоем случае транзакционная таблица только одна - это ORDERS. Если все правильно проиндексировано и оптимизатор в базе не полный лох (а он даже в мусколе не лох), то все у тебя будет ок. Если таки лох - похинтуй запросы руками, хотя я последний хинт писал еще для девятого Оракла, начиная с десятки CBO сам нормально допетривает.

Если у тебя заказов десятки миллионов в неделю (в чем я лично сомневаюсь), то можешь подумать о разных способах оптимизации, например о секционировании этой таблицы.

NoSQL твою проблему не решит: проблема, скорее всего, у тебя в голове (если у тебя не десятки миллионов заказов в неделю).

Исходная версия alex_the_v, :

Насколько я знаю, соединение - тяжелая операция

Месье был покусан MySQL 3.3?

Когда проектируют схему, то исходят из третьей нормальной формы. Потом (я подчеркиваю - потом, не сразу) участки, на которых возникают серьезные нерешаемые (я подчеркиваю - серьезные и нерешаемые) проблемы с производительностью, денормализуют.

В твоем случае транзакционная таблица только одна - это ORDERS. Если все правильно проиндексировано и оптимизатор в базе не полный лох (а он даже в мусколе не лох), то все у тебя будет ок. Если таки лох - похинтуй запросы руками, хотя я последний хинт писал еще для девятого Оракла.

Если у тебя заказов десятки миллионов в неделю (в чем я лично сомневаюсь), то можешь подумать о разных способах оптимизации, например о секционировании этой таблицы.

NoSQL твою проблему не решит: проблема, скорее всего, у тебя в голове (если у тебя не десятки миллионов заказов в неделю).