|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
Прочитал из "ценных указаний". Насколько оправдана такая инструкция? "Указания"Везде, где необходимо удалить более 1000 строк из таблицы нужно использовать механизмы, исключающие прямое удаление (например, переименование записей) и последующую сборку мусора в периоды низкой нагрузки на сервер. Нельзя использовать Foreign Key. Все связи в таблицах должны обрабатываться в запросах операциями JOIN при чем предпочтительно использовать INNER JOIN и LEFT JOIN. В некоторых случаях можно использовать FULL JOIN. RIGHT JOIN использовать не нужно. Для всех полей за редким исключением и особых случаев при создании таблиц нужно ставить ALLOW NULLS. Не использовать никаких CONSTRAINTS кроме Default Value. Не использовать триггеры. Собственно, база сваливает данные для аналитики по продажам в большом количестве ежедневно. Основные запросы на аналитику по продажам товаров. Без схемы данных. ============================================================================================================ "О, сколько нам открытий чудных готовит просвещения дух, и опыт - сын ошибок трудных, и гений - парадоксов друг, и случай - бог изобретатель" (Пушкин, однако). ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 14:53 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
dab2 Прочитал из "ценных указаний". Насколько оправдана такая инструкция? "Указания"Везде, где необходимо удалить более 1000 строк из таблицы нужно использовать механизмы, исключающие прямое удаление (например, переименование записей) и последующую сборку мусора в периоды низкой нагрузки на сервер. Нельзя использовать Foreign Key. Все связи в таблицах должны обрабатываться в запросах операциями JOIN при чем предпочтительно использовать INNER JOIN и LEFT JOIN. В некоторых случаях можно использовать FULL JOIN. RIGHT JOIN использовать не нужно. Для всех полей за редким исключением и особых случаев при создании таблиц нужно ставить ALLOW NULLS. Не использовать никаких CONSTRAINTS кроме Default Value. Не использовать триггеры. Собственно, база сваливает данные для аналитики по продажам в большом количестве ежедневно. Основные запросы на аналитику по продажам товаров. Без схемы данных. ============================================================================================================ "О, сколько нам открытий чудных готовит просвещения дух, и опыт - сын ошибок трудных, и гений - парадоксов друг, и случай - бог изобретатель" (Пушкин, однако). Для хранилищ данных -- абсолютно правильная и оправданная инструкция. Тригерры, внешние ключи и прочие констрейнты -- в DWH элементы чужеродные. А вообще -- изучайте якорную модель и все изменения делайте только INSERT-ами . ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 15:06 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
dab2, часть этих указаний направлены на оптимизация вставки. Я так понимаю, что вы решаете другую задачу? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 15:26 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
dab2, "Нельзя использовать Foreign Key" все эти "нельзя" не имеют смысла в общем случае. все хорошо в своей области. если мы пишем систему критическую по связанности данным, то нельзя БЕЗ форейн кеев. поэтому лучше сразу учтонять "в случае двх, не рекомендуем использовать форен кеи" ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 15:32 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
авторДля всех полей за редким исключением и особых случаев при создании таблиц нужно ставить ALLOW NULLS интересно, а это зачем? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 15:35 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
londinium авторДля всех полей за редким исключением и особых случаев при создании таблиц нужно ставить ALLOW NULLS интересно, а это зачем?Пока не знаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 15:43 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
StarikNavy dab2, "Нельзя использовать Foreign Key" все эти "нельзя" не имеют смысла в общем случае. все хорошо в своей области. если мы пишем систему критическую по связанности данным, то нельзя БЕЗ форейн кеев. поэтому лучше сразу учтонять "в случае двх, не рекомендуем использовать форен кеи" Вы лучше объясните почему. Потому что вставки массовые и наличие FK -- это серьезный тормоз. Да и OLTP системы можно написать так, то код гарантирует валидность данных. Более того, в двх загрузка может идти параллельно и по разным расписаниям, поэтому ситуация, когда не на что ссылаться, довольно частая. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 15:45 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
Пока я юнга на этом корабле! )) ХЗ куда плывём. По ходу плавания напишу подробности, тема интересная, я уже понял. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 15:50 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
a_voronin Потому что вставки массовые и наличие FK -- это серьезный тормоз a_voronin Да и OLTP системы можно написать так, то код гарантирует валидность данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 15:56 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
londinium авторДля всех полей за редким исключением и особых случаев при создании таблиц нужно ставить ALLOW NULLS интересно, а это зачем? ну возможно это не dwh, а стейдж база и там должны быть допустимы любые, неполные или кривые данные, главное вставить полностью и быстро ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 15:57 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
invm И получится свой механизм, повторяющий работу FK. ..., только с ошибками. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 16:40 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
invm a_voronin Потому что вставки массовые и наличие FK -- это серьезный тормоз a_voronin Да и OLTP системы можно написать так, то код гарантирует валидность данных. А потом их надо включать. И truncate не будет работать, а он в двх распространенное явление. В общем в двх форейн кей есть зло. И никаким механизмом повторяющим внешние ключи это не будет. Если вы правильно делаете транзакции и у вас в них нет багов, то все вставляется целостно. Если вы создаете заказ и прямо в этой транзакции вставляете юзера или он пришел в качестве параметра, а стало быть есть. А потом юзер не удаляется, а метится как удаленный признаком, то никаких внешних ключей вам не надо. И скажу вам по секрету -- в высоконагруженных oltp системах внешние ключи тоже убивают. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 16:40 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
a_voronin А потом их надо включать. a_voronin Если вы правильно делаете транзакции и у вас в них нет багов, то все вставляется целостно. Где гарантия, что этот контролер ничего не пропустит? И что контролер, контролирующий контролера тоже? Декларативную целостность и придумали в том числе и для того, чтобы избавиться от контролеров. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 17:23 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
С 2016 сервера, если правильно помню, были приняты меры по ускорению проверки внешних ключей. На 2000 сервере действительно были сложности, припоминаю. Если речь идет о проверке нескольких сотен внешних ключей, то наверное, замедление в работе появится. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 17:33 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
Сразу вспомнился анекдот про пять бабуинов. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 18:09 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
dab2, Кроме этого >>при создании таблиц нужно ставить ALLOW NULLS все остальное нормально для dwh ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 19:03 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
Критик dab2, Кроме этого >>при создании таблиц нужно ставить ALLOW NULLS все остальное нормально для dwh А почему можно использовать Left join, но нельзя Right join? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 21:06 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
uaggster А почему можно использовать Left join, но нельзя Right join? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 21:42 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
uaggster Критик dab2, Кроме этого >>при создании таблиц нужно ставить ALLOW NULLS все остальное нормально для dwh А почему можно использовать Left join, но нельзя Right join? Вероятно, для стандартизации. Эти методы соединения по сути идентичны, поэтому не стоит ломать голову, если можно обойтись только left вместо left и right-соединений. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2019, 21:55 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
uaggster Критик dab2, Кроме этого >>при создании таблиц нужно ставить ALLOW NULLS все остальное нормально для dwh А почему можно использовать Left join, но нельзя Right join? Лично я не знаю почему, но за свою карьеру нигде не использовал RIGHT JOIN. FULL JOIN использовал всего 3 раза. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2019, 09:21 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
invm a_voronin А потом их надо включать. a_voronin Если вы правильно делаете транзакции и у вас в них нет багов, то все вставляется целостно. Где гарантия, что этот контролер ничего не пропустит? И что контролер, контролирующий контролера тоже? Декларативную целостность и придумали в том числе и для того, чтобы избавиться от контролеров. Есть способы построить БД так и следовать шаблонам написания кода так, что никакой контроллер не нужен. Я говорю о ХД. В OLTP как правило есть небольшое число таблиц большого размера, где это критично и там надо написать некоторое кол-во кода, который надо хорошо проверить и протестировать и который для ускорения работает без констрейнтов. Одно дело, если вы проводите платежи, другие дело, если вы скидывает информацию в исторический лог, где эти констрейнты никому не нужны. Вообще введение принципа -- ничего не удалять, только метить DELETED = 1 это шаг к тому, чтобы избавиться от внешних ключей. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2019, 09:30 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
a_voronin FULL JOIN использовал всего 3 раза. a_voronin Есть способы построить БД так и следовать шаблонам написания кода так, что никакой контроллер не нужен. a_voronin Вообще введение принципа -- ничего не удалять, только метить DELETED = 1 это шаг к тому, чтобы избавиться от внешних ключей. Констрейнты всего лишь инструмент. И просто нужно уметь им пользоваться. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2019, 09:59 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
a_voronin Есть способы построить БД так и следовать шаблонам написания кода так, что никакой контроллер не нужен. Я говорю о ХД. Все равно нужен будет контролер, который будет проверять на следование шаблонам, иначе получится полная дичь даже с 2мя разработчиками. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2019, 10:15 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
Критик a_voronin Есть способы построить БД так и следовать шаблонам написания кода так, что никакой контроллер не нужен. Я говорю о ХД. Все равно нужен будет контролер, который будет проверять на следование шаблонам, иначе получится полная дичь даже с 2мя разработчиками. Как насчет того, чтобы использовать генератор кода, и возложить функцию контроллера на код. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2019, 11:26 |
|
Ценные указания. Прошу обсудить.
|
|||
---|---|---|---|
#18+
a_voronin, А генератор кода кто напишет? А кто будет контролировать правильность генерации? И т.д. и т.п. Если есть критичные места, где нужно гарантировать целостность данных, то таки придется обеспечивать это средствами декларативной целостности. Ибо ничего другое эту целостность не гарантирует. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2019, 11:39 |
|
|
start [/forum/topic.php?fid=46&msg=39909402&tid=1686684]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
111ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 336ms |
total: | 542ms |
0 / 0 |