ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Что лучше: FK или триггеры проверки целостности?
25 сообщений из 63, страница 2 из 3
  2  все
Что лучше: FK или триггеры проверки целостности?
    #39633153
Фотография DarkMaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DarkMaster
Участник
m7m,

Да, но легче читать запрос когда подвязываются таблицы-справочники, а не 1 справочник много раз. Ну это лично для меня.
...
Рейтинг: 0 / 0
19.04.2018, 13:39
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633169
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Старый плюшевый мишка
Участник
Гаджимурадов РустамВы, кстати, "универсальные" справочники практиковали?
Это когда несколько однотипных справочников
объединяются по вертикали - ID, Ref_ID, Value, ... ?


Нет. Чем проще и каноничнее структура, тем проще жизнь. Имхо.
...
Рейтинг: 0 / 0
19.04.2018, 14:06
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633174
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Старый плюшевый мишка
Участник
rdb_devСтарый плюшевый мишкаА теперь представим себе мастер-таблицу, скажем, статусов документов. Нуусс, скажем, счетов.

Новый
В работе
Оплачен
Отгружено
Закрыт
NEW, IN_WORK, PAID, SHIPPED, CLOSED - ASCII символы этих слов слева направо легко умещаются в BIGINT от старшего байта к младшему, прекрасно сортируются и интерпретируются без всяких мастер-таблиц. Остается лишь прописать соответствующие числовые константы в ограничении CHECK соответствующего поля и создать по этому полю индекс.

Речь не о том, что во что впихуемо. За "создать по этому полю индекс" - двойка. Ты ничего не понял.
...
Рейтинг: 0 / 0
19.04.2018, 14:09
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633177
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Старый плюшевый мишкаЗа "создать по этому полю индекс" - двойка. Ты ничего не понял.Обоснуешь? Объяснишь?
...
Рейтинг: 0 / 0
19.04.2018, 14:13
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633179
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WildSery
Участник
Пробовал.

Удобно использовать для простых перечислений, которые состоят только из наименования и ещё пары "базовых" признаков, типа пометки удаления, признака группы и родителя/иерархии.

Собственно, и всё.
Остальное признано нецелесообразным.
...
Рейтинг: 0 / 0
19.04.2018, 14:14
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633190
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Старый плюшевый мишка
Участник
rdb_devСтарый плюшевый мишкаЗа "создать по этому полю индекс" - двойка. Ты ничего не понял.Обоснуешь? Объяснишь?

Да раком сервак встанет, если попытается на заметных объёмах его в запросах использовать. Причём не во всех запросах, а в зависимости от количества дубликатов искомого значения. Можно год не наступить на мину, а потом кааак бабахнет! И ресторить сутками будет, строя этот индекс. Весь сыр-бор с отказом от FK именно для того, чтобы от него избавиться.
...
Рейтинг: 0 / 0
19.04.2018, 14:20
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633202
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Старый плюшевый мишкаДа раком сервак встанет, если попытается на заметных объёмах его в запросах использовать. Причём не во всех запросах, а в зависимости от количества дубликатов искомого значения. Можно год не наступить на мину, а потом кааак бабахнет! И ресторить сутками будет, строя этот индекс. Весь сыр-бор с отказом от FK именно для того, чтобы от него избавиться.Чот я не пойму... В FK у тебя суррогатный ключ, например тот же BIGINT, по которому, в случае FK, будет построен индекс, но ко всему прочему, еще будет осуществляться проверка на наличие соответствующего ключа в мастер-таблице. Так почему в случае моих константных значений BIGINT сервер встанет раком, а в случае FK-PK - не встанет?
...
Рейтинг: 0 / 0
19.04.2018, 14:35
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633204
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pastor
Участник
Гаджимурадов РустамDarkMaster> Ну то, что запросы становятся развесистыми - уже минус.

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

> Ну и постоянные кастование.

Это ты про Value1, Value2 и пр. универсальные поля?

> Если честно - помню только общие нехорошие впечатления,

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


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

лукапы делать не сильно удобно. приходится генерить на ходу.

все значения текстовые.

справочники, которые не могут редактироваться пользователями - "пол" - забиваются в домены ( M F U), расшифровки - в справочник описания доменов (F - Женский)

были попытки создания древовидной (точнее иерархической) структуры документов, сущностей и пр, но не взлетело. канонические структуры оказались быстрее в разработке, работе и сопровождении.
...
Рейтинг: 0 / 0
19.04.2018, 14:37
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633236
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Старый плюшевый мишка
Участник
rdb_devСтарый плюшевый мишкаДа раком сервак встанет, если попытается на заметных объёмах его в запросах использовать. Причём не во всех запросах, а в зависимости от количества дубликатов искомого значения. Можно год не наступить на мину, а потом кааак бабахнет! И ресторить сутками будет, строя этот индекс. Весь сыр-бор с отказом от FK именно для того, чтобы от него избавиться.Чот я не пойму... В FK у тебя суррогатный ключ, например тот же BIGINT, по которому, в случае FK, будет построен индекс, но ко всему прочему, еще будет осуществляться проверка на наличие соответствующего ключа в мастер-таблице. Так почему в случае моих константных значений BIGINT сервер встанет раком, а в случае FK-PK - не встанет?

Ой фсё...
...
Рейтинг: 0 / 0
19.04.2018, 15:04
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633237
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Старый плюшевый мишка
Участник
Старый плюшевый мишкаrdb_devпропущено...
Чот я не пойму... В FK у тебя суррогатный ключ, например тот же BIGINT, по которому, в случае FK, будет построен индекс, но ко всему прочему, еще будет осуществляться проверка на наличие соответствующего ключа в мастер-таблице. Так почему в случае моих константных значений BIGINT сервер встанет раком, а в случае FK-PK - не встанет?

Ой фсё...

Подробнее - я отвечаю за то, что я пишу, а не за то, что ты читаешь :)
...
Рейтинг: 0 / 0
19.04.2018, 15:05
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633262
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Старый плюшевый мишкаПодробнее - я отвечаю за то, что я пишу, а не за то, что ты читаешь :)😆
...
Рейтинг: 0 / 0
19.04.2018, 15:39
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633292
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WildSery
Участник
rdb_dev,

Ты поищи, поищи, где о FK такое написано.
Речь шла об индексе, и никакой разницы, FK он или не FK.
...
Рейтинг: 0 / 0
19.04.2018, 16:22
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633429
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
DarkMaster> Да, но легче читать запрос когда подвязываются таблицы-справочники,
DarkMaster> а не 1 справочник много раз. Ну это лично для меня.

С алиасом разницы практически никакой нет. Но это вкусовщина, в любом случае.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
19.04.2018, 21:38
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633430
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
В общем, всем спасибо за мнения и впечатления.

pastor> были попытки создания древовидной (точнее иерархической)
pastor> структуры документов, сущностей и пр, но не взлетело

В смысле некая EAV-light или тот же справочник, но ещё и
древовидный (в чём его древовидность-то заключается) ?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
19.04.2018, 21:40
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633449
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
WildSery, бывает, я, порой, не догоняю о чем речь и потому переспрашиваю. И?
...
Рейтинг: 0 / 0
19.04.2018, 23:22
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633488
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m7m
Участник
KreatorXXIЯ вот приводил пример леса джойнов:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
select a.longname, b.longname, c.shortname, d.longname, e.longname, f.shortname
from sprav a
        inner join sprav b on b.id2=a.id and b.priznak=2
        inner join sprav c on c.id2=b.id and c.priznak=3
        inner join sprav d on d.id3=a.id2  and d.priznak=4
        inner join sprav e on e.id2=d.id and e.priznak=5
        inner join sprav f on f.id3=e.id and f.priznak=6
where a.priznak=1



Ну нечитаемо совсем. Если только комментарии к каждой строке...
Конечно нечитаемо, ты один справочник сам с собой связываешь
а если вот такое
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
select Z......, A.Longname as Areaname, B.Longname as BoilerName, C.Shortname as Claimshortname,
       D.Longname as Districtname, Dp.Longname as Departmentname,
  from Doc Z
    join Sprav A on A.Id = Z.Area
    join Sprav B on B.Id = Z.Boiler
    join Sprav C on C.Id = Z.Claim
    join Sprav Di on Di.Id = Z.District
    join Sprav Dp on Dp.Id = Z.Department
    .......................
  where..................


так совсем другой вид
...
Рейтинг: 0 / 0
20.04.2018, 07:20
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633543
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WildSery
Участник
rdb_dev,

Моё дело метёлкой махать, а не подталкивать отстающих.
...
Рейтинг: 0 / 0
20.04.2018, 09:33
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633592
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KreatorXXI
Участник
m7m,

Я привёл как-раз свой пример, где "универсальность" справочников доведена до маразма. У нас именно так они и перевязаны.
...
Рейтинг: 0 / 0
20.04.2018, 10:30
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633662
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
m7m
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
select Z......, A.Longname as Areaname, B.Longname as BoilerName, C.Shortname as Claimshortname,
       D.Longname as Districtname, Dp.Longname as Departmentname,
  from Doc Z
    join Sprav A on A.Id = Z.Area
    join Sprav B on B.Id = Z.Boiler
    join Sprav C on C.Id = Z.Claim
    join Sprav Di on Di.Id = Z.District
    join Sprav Dp on Dp.Id = Z.Department
    .......................
  where..................



Откуда требование ещё и глобального одного-на-всю-БД источника ID для всех объектов

Чтобы не случилось, что например Z[1].Area = Z[8].District или Z[123].Department = Z[47].Claim
...
Рейтинг: 0 / 0
20.04.2018, 11:54
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633665
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
KreatorXXI,

Такое ощущение, что вы там аналог Windows Registry замутили.

Наверное тогда как и в Windows надо было делить на две сущности, делать две таблицы.

1) дерево структуры, ноды
2) Key-Value значения, привязанные к конкретной ноде

Тогда ты сначала выбираешь ноду по первой таблице, а потом начинаешь е ней аттрибуты подтягивать?
...
Рейтинг: 0 / 0
20.04.2018, 11:56
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633711
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m7m
Участник
AriochОткуда требование ещё и глобального одного-на-всю-БД источника ID для всех объектов
Ну не "одного-на-всю-БД источника ID" а только для тех кто в общем справочнике
Я не вижу в этом ничего плохого, а вот что увидел ты в этом плохого я не знаю
и мне это малость интересно
...
Рейтинг: 0 / 0
20.04.2018, 12:48
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633713
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
AriochТогда ты сначала выбираешь ноду по первой таблице, а потом начинаешь е ней аттрибуты подтягивать?Это уже динамическая ORM. :)
...
Рейтинг: 0 / 0
20.04.2018, 12:52
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633765
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KreatorXXI
Участник
Arioch,

У нас сложней. Одна запись справочника может иметь до четырёх форейн-записей других справочников. Пока до четырёх. И деревянная структура тоже держится. Я когда увидел, что коллеги наваяли (я был новый), обалдел. Нет, связывать надо, никуда не деться. Но читабельность... Беру список признаков и разбираюсь часами. ИМХО, дурдом.
...
Рейтинг: 0 / 0
20.04.2018, 13:51
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633767
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
m7m,

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

m7mтолько для тех кто в общем справочнике

в добавок еще ненужное усложнение системы

для одних объектов мы берем нoвые ID одним методом из одного хранилища, а для других - другим методом из других хранилищ. Это нужно всегда помнить и нигде не перепутать, вмеcто унификации кода.

А если потом какой-то изначально отдельный объект захочется внести в справочник?
...
Рейтинг: 0 / 0
20.04.2018, 13:53
| Ответить | Цитировать | Написать  
Что лучше: FK или триггеры проверки целостности?
    #39633770
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
KreatorXXIОдна запись справочника может иметь до четырёх форейн-записей других справочников.

зачем?

KreatorXXIПока до четырёх.

ага, молотком и матерью всунуть шахматку на уровень структур RDBMS, потом грызть грааль "как сделать универсальный запрос, чтобы по любому из одинаковых столбцов...."
...
Рейтинг: 0 / 0
20.04.2018, 13:56
| Ответить | Цитировать | Написать  
25 сообщений из 63, страница 2 из 3
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Что лучше: FK или триггеры проверки целостности?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=39633765&tid=1561143]:
 0ms
get settings:
 11ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 53ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 55ms
get tp. blocked users:
 1ms
others: 13ms
total:  167ms
созд. / загр.: 167ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]