Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Проектирование БД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
 Re: Помогите довести до ума модель данных склада  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1853
Cane Cat Fisher
s_ustinov
пропущено...

Не помню Дублирование данных - это ВСЕГДА нарушение нормализации, так как неключевой столбец (количество) зависит от записей в других таблицах.


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

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

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

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

Прежде чем обвинять других в беспредметности - предложите свой вариант, желательно в виде кода. И потом обсудим. А без конкретных предложений все рассуждения - не более чем попытки замаскировать некомпетентность общими фразами.
18 июл 17, 00:46    [20652150]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
Naf
Member

Откуда: Москва
Сообщений: 2685
http://www.sql.ru/forum/622860/shablon-resursy-nakopleniya
18 июл 17, 09:09    [20652409]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1853
Naf
http://www.sql.ru/forum/622860/shablon-resursy-nakopleniya

Лавры тормозной 1С спать не дают. :)
Измерьте скорость записи и расскажите нам результат.
Вы серьезно думаете, что триггер отработает быстрее индекса?
18 июл 17, 09:33    [20652483]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
Naf
Member

Откуда: Москва
Сообщений: 2685
Ну вот когда перед самой этой записью будут проверяться остатки (чтобы в минус не уйти), тогда и узнаем
18 июл 17, 09:41    [20652512]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
Cane Cat Fisher
Member

Откуда:
Сообщений: 1466
s_ustinov
Ок, расскажите нам всем решение, которое покажет производительность выше, чем индексы.
Пока что никто из "клуба любителей хранения остатков" не предложил ни одного варианта, который работал бы быстрее предложенного мной варианта с индексами


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

Если же мы храним остатки в явном виде в таблицах, мы, разумеется, тоже сталкиваемся с затратами на их вычисление и поддержание, но эти проблемы гораздо более управляемы. Только и всего.
18 июл 17, 10:12    [20652644]     Ответить | Цитировать Сообщить модератору
 Re: Помогите довести до ума модель данных склада  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1853
Cane Cat Fisher
s_ustinov
Ок, расскажите нам всем решение, которое покажет производительность выше, чем индексы.
Пока что никто из "клуба любителей хранения остатков" не предложил ни одного варианта, который работал бы быстрее предложенного мной варианта с индексами


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

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

Я правильно понимаю - вы утверждаете, что при обновлении другой таблицы триггером проблем с блокировками и производительностью меньше, чем с использованием индекса?
19 июл 17, 01:14    [20655989]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
Все форумы / Проектирование БД Ответить