|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
m7m, Да, но легче читать запрос когда подвязываются таблицы-справочники, а не 1 справочник много раз. Ну это лично для меня. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 13:39 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамВы, кстати, "универсальные" справочники практиковали? Это когда несколько однотипных справочников объединяются по вертикали - ID, Ref_ID, Value, ... ? Нет. Чем проще и каноничнее структура, тем проще жизнь. Имхо. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 14:06 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
rdb_devСтарый плюшевый мишкаА теперь представим себе мастер-таблицу, скажем, статусов документов. Нуусс, скажем, счетов. Новый В работе Оплачен Отгружено Закрыт NEW, IN_WORK, PAID, SHIPPED, CLOSED - ASCII символы этих слов слева направо легко умещаются в BIGINT от старшего байта к младшему, прекрасно сортируются и интерпретируются без всяких мастер-таблиц. Остается лишь прописать соответствующие числовые константы в ограничении CHECK соответствующего поля и создать по этому полю индекс. Речь не о том, что во что впихуемо. За "создать по этому полю индекс" - двойка. Ты ничего не понял. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 14:09 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаЗа "создать по этому полю индекс" - двойка. Ты ничего не понял.Обоснуешь? Объяснишь? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 14:13 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Пробовал. Удобно использовать для простых перечислений, которые состоят только из наименования и ещё пары "базовых" признаков, типа пометки удаления, признака группы и родителя/иерархии. Собственно, и всё. Остальное признано нецелесообразным. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 14:14 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
rdb_devСтарый плюшевый мишкаЗа "создать по этому полю индекс" - двойка. Ты ничего не понял.Обоснуешь? Объяснишь? Да раком сервак встанет, если попытается на заметных объёмах его в запросах использовать. Причём не во всех запросах, а в зависимости от количества дубликатов искомого значения. Можно год не наступить на мину, а потом кааак бабахнет! И ресторить сутками будет, строя этот индекс. Весь сыр-бор с отказом от FK именно для того, чтобы от него избавиться. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 14:20 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаДа раком сервак встанет, если попытается на заметных объёмах его в запросах использовать. Причём не во всех запросах, а в зависимости от количества дубликатов искомого значения. Можно год не наступить на мину, а потом кааак бабахнет! И ресторить сутками будет, строя этот индекс. Весь сыр-бор с отказом от FK именно для того, чтобы от него избавиться.Чот я не пойму... В FK у тебя суррогатный ключ, например тот же BIGINT, по которому, в случае FK, будет построен индекс, но ко всему прочему, еще будет осуществляться проверка на наличие соответствующего ключа в мастер-таблице. Так почему в случае моих константных значений BIGINT сервер встанет раком, а в случае FK-PK - не встанет? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 14:35 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамDarkMaster> Ну то, что запросы становятся развесистыми - уже минус. Если мы говорим об одном и том же, то по сути добавляется только одно (или два) условия в where (к одному/двум полям одной таблицы). Не так уж и развесисто. С учетом нормальных алиасов как подсказали выше - и читаемость особо не страдает. > Ну и постоянные кастование. Это ты про Value1, Value2 и пр. универсальные поля? > Если честно - помню только общие нехорошие впечатления, Меня интересуют впечатления, неизвестные грабли и пр, исходники как раз малоинтересны, там сложностей нет. Для справчоников, создаваемых пользователями. Т.е. создается критерий "размер ноги", к нему набор допустимых значений потом "размер головы", "длина лыж", "длина палок" лукапы делать не сильно удобно. приходится генерить на ходу. все значения текстовые. справочники, которые не могут редактироваться пользователями - "пол" - забиваются в домены ( M F U), расшифровки - в справочник описания доменов (F - Женский) были попытки создания древовидной (точнее иерархической) структуры документов, сущностей и пр, но не взлетело. канонические структуры оказались быстрее в разработке, работе и сопровождении. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 14:37 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
rdb_devСтарый плюшевый мишкаДа раком сервак встанет, если попытается на заметных объёмах его в запросах использовать. Причём не во всех запросах, а в зависимости от количества дубликатов искомого значения. Можно год не наступить на мину, а потом кааак бабахнет! И ресторить сутками будет, строя этот индекс. Весь сыр-бор с отказом от FK именно для того, чтобы от него избавиться.Чот я не пойму... В FK у тебя суррогатный ключ, например тот же BIGINT, по которому, в случае FK, будет построен индекс, но ко всему прочему, еще будет осуществляться проверка на наличие соответствующего ключа в мастер-таблице. Так почему в случае моих константных значений BIGINT сервер встанет раком, а в случае FK-PK - не встанет? Ой фсё... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 15:04 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаrdb_devпропущено... Чот я не пойму... В FK у тебя суррогатный ключ, например тот же BIGINT, по которому, в случае FK, будет построен индекс, но ко всему прочему, еще будет осуществляться проверка на наличие соответствующего ключа в мастер-таблице. Так почему в случае моих константных значений BIGINT сервер встанет раком, а в случае FK-PK - не встанет? Ой фсё... Подробнее - я отвечаю за то, что я пишу, а не за то, что ты читаешь :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 15:05 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаПодробнее - я отвечаю за то, что я пишу, а не за то, что ты читаешь :)😆 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 15:39 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
rdb_dev, Ты поищи, поищи, где о FK такое написано. Речь шла об индексе, и никакой разницы, FK он или не FK. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 16:22 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
DarkMaster> Да, но легче читать запрос когда подвязываются таблицы-справочники, DarkMaster> а не 1 справочник много раз. Ну это лично для меня. С алиасом разницы практически никакой нет. Но это вкусовщина, в любом случае. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 21:38 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
В общем, всем спасибо за мнения и впечатления. pastor> были попытки создания древовидной (точнее иерархической) pastor> структуры документов, сущностей и пр, но не взлетело В смысле некая EAV-light или тот же справочник, но ещё и древовидный (в чём его древовидность-то заключается) ? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 21:40 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
WildSery, бывает, я, порой, не догоняю о чем речь и потому переспрашиваю. И? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 23:22 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
KreatorXXIЯ вот приводил пример леса джойнов: Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
Ну нечитаемо совсем. Если только комментарии к каждой строке... Конечно нечитаемо, ты один справочник сам с собой связываешь а если вот такое Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
так совсем другой вид ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 07:20 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
rdb_dev, Моё дело метёлкой махать, а не подталкивать отстающих. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 09:33 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
m7m, Я привёл как-раз свой пример, где "универсальность" справочников доведена до маразма. У нас именно так они и перевязаны. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 10:30 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
m7m Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Откуда требование ещё и глобального одного-на-всю-БД источника ID для всех объектов Чтобы не случилось, что например Z[1].Area = Z[8].District или Z[123].Department = Z[47].Claim ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 11:54 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
KreatorXXI, Такое ощущение, что вы там аналог Windows Registry замутили. Наверное тогда как и в Windows надо было делить на две сущности, делать две таблицы. 1) дерево структуры, ноды 2) Key-Value значения, привязанные к конкретной ноде Тогда ты сначала выбираешь ноду по первой таблице, а потом начинаешь е ней аттрибуты подтягивать? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 11:56 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
AriochОткуда требование ещё и глобального одного-на-всю-БД источника ID для всех объектов Ну не "одного-на-всю-БД источника ID" а только для тех кто в общем справочнике Я не вижу в этом ничего плохого, а вот что увидел ты в этом плохого я не знаю и мне это малость интересно ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 12:48 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
AriochТогда ты сначала выбираешь ноду по первой таблице, а потом начинаешь е ней аттрибуты подтягивать?Это уже динамическая ORM. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 12:52 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Arioch, У нас сложней. Одна запись справочника может иметь до четырёх форейн-записей других справочников. Пока до четырёх. И деревянная структура тоже держится. Я когда увидел, что коллеги наваяли (я был новый), обалдел. Нет, связывать надо, никуда не деться. Но читабельность... Беру список признаков и разбираюсь часами. ИМХО, дурдом. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 13:51 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
m7m, ненужная зависимость разных сущностей между собой - больше надо помнить и учитывать, а гибкость меньше m7mтолько для тех кто в общем справочнике в добавок еще ненужное усложнение системы для одних объектов мы берем нoвые ID одним методом из одного хранилища, а для других - другим методом из других хранилищ. Это нужно всегда помнить и нигде не перепутать, вмеcто унификации кода. А если потом какой-то изначально отдельный объект захочется внести в справочник? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 13:53 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
KreatorXXIОдна запись справочника может иметь до четырёх форейн-записей других справочников. зачем? KreatorXXIПока до четырёх. ага, молотком и матерью всунуть шахматку на уровень структур RDBMS, потом грызть грааль "как сделать универсальный запрос, чтобы по любому из одинаковых столбцов...." ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 13:56 |
|
|
start [/forum/topic.php?fid=40&msg=39633592&tid=1561143]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
63ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 168ms |
0 / 0 |