размер базы Vs скорость

[mulder]

размер базы Vs скорость

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

 

[Артем]

я когда-то спрашивал о чем-то подобном - мне посоветовали то, что я посоветую тебе.
создай две таблицы по миллиону записей и протестируй

 

[Demiurg]

Re: размер базы Vs скорость

Автор оригинала: mulder
Есть ли смысл хранить в базе повторяющиеся данные для повышения скорости работы?
Например есть
таблица товаров с ценами,
таблица заказов и
таблица заказанных товаров и их количества.
Стоит ли в таблице заказов хранить суммарную цену заказа или лучше каждый раз пересчитывать ее обьединяя эти таблицы?

Все зависит от конкретной задачи. Архетектура базы данных вещь сложная. Так что конкретных советов тебе вряд ли дадут.

 

[С.]

Re: размер базы Vs скорость

Автор оригинала: mulder
Есть ли смысл хранить в базе повторяющиеся данные для повышения скорости работы?
Например есть
таблица товаров с ценами,
таблица заказов и
таблица заказанных товаров и их количества.
Стоит ли в таблице заказов хранить суммарную цену заказа или лучше каждый раз пересчитывать ее обьединяя эти таблицы?

При создании архитектуры базы данных есть очень строгое правило: никакого дублирования данных ни при каких условиях. Нарушение этого правила карается появлением дурацких, но очень неприятных багов. Скорость здесь стоит на последнем месте. Когда к тебе придет заказчик и будет показывать неверные результаты, он не удовлетворится твоим объяснение, что это было сделано для ускорения процессов.

 

[dr.vint]

Ну почему же,

контролируемая избыточность иногда бывает полезна

 

[С.]

Автор оригинала: dr.vint
Ну почему же,
контролируемая избыточность иногда бывает полезна

Например?

 

[Demiurg]

Автор оригинала: С.
Например?

Для чего тогда делают репликацию ?

 

[mulder]

А нормальными словами?..

 

[tony2001]

Автор оригинала: mulder
А нормальными словами?..

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

2 C.
насчет избыточности - имхо все должно быть в разумных размерах.
и не надо кидаться в крайности.

 

[mulder]

А кто это корзину целые сутки помнит???
Ты либо откладывешь без цен (как на ОЗОНЕ) либо оформаляешь заказ

 

[С.]

Автор оригинала: tony2001
ситуация:
я зашел, добавил себе в корзину кучу товаров. вышел.
зашел на следующий день оплатить.
а вчера вечером цены на половину из выбранных товаров поменялись.
если тебя не беспокоит то, что я заплачу по вчерашним ценам, то пиши их в корзину, если беспокоит - не пиши.
лично я бы не писал - это лишнее, имхо.
2 C.
насчет избыточности - имхо все должно быть в разумных размерах.
и не надо кидаться в крайности.

Корзина по вчерашним ценам (если это оговорено в ТЗ) - не избыточность даных.

А нас счет не крайности, вы примерами бейте, надежнее получится.

 

[tony2001]

2 mulder:
>А кто это корзину целые сутки помнит???
а почему бы и нет?
мало ли кому как хочется реализовать движок магазина!

2 C.
>Корзина по вчерашним ценам (если это оговорено в ТЗ) - не
>избыточность даных.
не спорю
>А нас счет не крайности, вы примерами бейте, надежнее получится.
я про "никакого дублирования данных ни при каких условиях".
имхо - это крайность.

 

[С.]

Автор оригинала: tony2001
я про "никакого дублирования данных ни при каких условиях".
имхо - это крайность.

Я и прошу привести хоть один пример, когда избыточность данных была оправдана.

 

[Demiurg]

Автор оригинала: С.
Я и прошу привести хоть один пример, когда избыточность данных была оправдана.

Репликация уже не является примером ?

 

[С.]

Автор оригинала: Demiurg
Репликация уже не является примером ?

Ага! И резервное копирование туда же, до кучи.

 

[tony2001]

Автор оригинала: С.
Я и прошу привести хоть один пример, когда избыточность данных была оправдана.

пример:
есть у меня категории (скажем книг) типа Программирование, Искусство и т.п., в них куча подкатегорий типа PHP, Театр и т.п.
В подкатегориях - куча книг. "Куча" - это тысячи и десятки тысяч.
Имеет ли смысл мне при просмотре просто главных категорий делать выборку по всех их детям и считать книги в них ? Или все же проще ввести у главных категорий доп. поле и менять его при каждом изменении у детей ?
Избыточность? Да, эти данные у меня есть уже в других таблицах.
Но чтобы их посчитать имхо надо сравнительно больше ресурсов, чем требуется для хранения int и больше времени, чем требуется для одного UPDATE при каждом изменении кол-ва у детей.
Кстати, пример из жизни и я пока не решил что с ним делать.
Поэтому не утверждаю, а задаю вопрос.

 

[Demiurg]

Автор оригинала: С.
Ага! И резервное копирование туда же, до кучи.

В каком то смысле да. Нельзя же все ставить в жертву высоким идеям. Если верить Дейту, то ни одна из современных комерчиских реализаций РБД не отвечает теоритическому идеалу (я уже молчу про mysql). Но ведь мы их используем, и будем использовать, по тому что главное для нас - конечный результат. Точно так же и с избыточностью данных.

 

[С.]

Автор оригинала: tony2001
пример:
есть у меня категории ...

Не знаю как ты намерен хранить категорию книги. Не словом же "Театр", а потом где-то в справочнике, что "Театр" относится к "Искусству".

Я бы сделал структурную кодировку:
100 - Программирование
101 - РНР
102 - Перл
...
200 - Искусство
201 - Театр
202 - Кино
...

С такой кодировкой никаких проблем выбирать в любом из двух срезов, да и дерево можно строить динамически на основе лишь справочника кодов.

 

[tony2001]

да, забыл сказать, а это важно:
две таблицы, конечно - родители и дети, объединение по id.
id = auto_increment (не вижу смысла заморачиваться потом с 100, 101 и т.п., имхо это только проблемы на голову свою иметь потом)

 

[С.]

Автор оригинала: Demiurg
В каком то смысле да. Нельзя же все ставить в жертву высоким идеям. Если верить Дейту, то ни одна из современных комерчиских реализаций РБД не отвечает теоритическому идеалу (я уже молчу про mysql). Но ведь мы их используем, и будем использовать, по тому что главное для нас - конечный результат. Точно так же и с избыточностью данных.

Если реализации БД по каким-то практическим причинам не отвечают идеалу, совсем не значит, что и теоретические основы их использования можно нарушать налево и направо