История изменений
Исправление 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 твою проблему не решит: проблема, скорее всего, у тебя в голове (если у тебя не десятки миллионов заказов в неделю).