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

Откуда:
Сообщений: 1271
Прописывать на уровне бд или это старый век?
__________________________________________________________________
THE TRUTH IS OUT THERE
2 авг 17, 14:49    [20695081]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
LSV
Member

Откуда: Киев
Сообщений: 29967
Связи (констрайнты) будут мешать разными способами.
Поэтому многие разработчики их принципиально не используют.

И правильно делают, ИМХО.
2 авг 17, 14:55    [20695107]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
mr_max
Member

Откуда:
Сообщений: 1271
LSV
Связи (констрайнты) будут мешать разными способами.
Поэтому многие разработчики их принципиально не используют.

И правильно делают, ИМХО.

согласен.
2 авг 17, 15:02    [20695131]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
ChA
Member

Откуда: Москва
Сообщений: 10354
LSV
Связи (констрайнты) будут мешать разными способами. Поэтому многие разработчики их принципиально не используют.

И правильно делают, ИМХО.
Да и таблицы устарели, надо держать всё в XML и NoSQL. И БД привязывать только к одному приложению, только кретин полагает, что БД могут пользоватся разными приложениями.

P.S. ДБ!
2 авг 17, 15:10    [20695167]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
stomsky
Member

Откуда: Волгоград
Сообщений: 124
LSV
Связи (констрайнты) будут мешать разными способами.

Каким образом FOREIGN KEY CONSTRAINT может мешать?
2 авг 17, 17:16    [20695693]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7576
stomsky
LSV
Связи (констрайнты) будут мешать разными способами.

Каким образом FOREIGN KEY CONSTRAINT может мешать?

Ну в принципе они могут мешать, конечно - их проверки небесплатны и увеличивают требуемые ресурсы на обновление данных.
Но реальные кейсы, когда имеет смысл давиться за микросекунды за счет надежности, прозрачности и самодокументируемости системы - они, ээ, редки, весьма редки.
2 авг 17, 18:11    [20695876]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
SERG1257
Member

Откуда:
Сообщений: 2491
Думаю, тут речь не о ресурсах.
Связи мешают девелоперам другим, они требуют дисциплины - с ними ничего так просто не грохнеш не вставиш,
скрипты приходится писать аккуратнее.
2 авг 17, 18:28    [20695933]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
azsx
Member

Откуда:
Сообщений: 485
автор
их проверки небесплатны и увеличивают требуемые ресурсы на обновление данных

Зато их проверки не напрасны, то есть если не делать ограничения на уровне БД, то эти ограничения надо делать на уровне логики.
зы
На самом деле я дублирую и в БД стараюсь делать и в программе проверки пишу. Но как правильно делать -- я не знаю.
3 авг 17, 04:21    [20696650]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
scf
Member

Откуда:
Сообщений: 1352
Имхо, зависит от базы.
Доводы за:
- если данные в базе имеют самостоятельную ценность (живут длительное время, используются более чем одним приложением)
- низкая квалификация программистов

Доводы против:
- требуется большая скорость вставки и другие способы оптимизации уже реализованы
- вставка сущности в сложную нормализованную базу может быть делом нетривиальным
3 авг 17, 08:38    [20696809]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
stomsky
Member

Откуда: Волгоград
Сообщений: 124
Кот Матроскин
stomsky
пропущено...

Каким образом FOREIGN KEY CONSTRAINT может мешать?

Ну в принципе они могут мешать, конечно - их проверки небесплатны и увеличивают требуемые ресурсы на обновление данных

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

scf
Доводы против:
- требуется большая скорость вставки и другие способы оптимизации уже реализованы
- вставка сущности в сложную нормализованную базу может быть делом нетривиальным

Ну т.е. надо принять за правило, что отказываться от внешних ключей надо там, где уже пожертвовали нормализацией?
Ведь даже если мы откажемся от FOREIGN KEY (как технической возможности РСУБД) мы же не откажемся от бизнес-требования "обеспечить ссылочную целостность данных"? Нас же не устроит, что, например, "Строка заказа" может существовать без привязки к "Заказу"? А если не устроит, то как без FOREIGN KEY будем обеспечивать выполнение этого бизнес-требования?
3 авг 17, 09:18    [20696903]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
LSV
Member

Откуда: Киев
Сообщений: 29967
А если не устроит, то как без FOREIGN KEY будем обеспечивать выполнение этого бизнес-требования?
Просто напишите логику, где всегда будет шапка у строки заказа. Только и всего.

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

Тож самое касается и триггеров, созданных для поддержки ФК.

Нарушение логики ФК всегда можно обнаружить и правильно отреагировать (н-р заново создать шапку или удалить/переместить осиротелые строки) при этом не выпадая в ошибки СУБД. Не всегда вообще возможно создание ФК. Тогда придется делать другое решение, т.е. применять несколько разных методов вместо одного.

зы: Тот, кто настаивает на использовании FOREIGN KEY просто мало работал с реальными данными. :)
3 авг 17, 09:58    [20696999]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
stomsky
Member

Откуда: Волгоград
Сообщений: 124
LSV
А если не устроит, то как без FOREIGN KEY будем обеспечивать выполнение этого бизнес-требования?
Просто напишите логику, где всегда будет шапка у строки заказа. Только и всего.

Давай на примере. Например, есть такая структура данных (T-SQL):
CREATE TABLE Orders
(
  OrderId INT IDENTITY (1, 1) NOT NULL,
....
  CONSTRAINT Orders_PK PRIMARY KEY(OrderId)
)
CREATE TABLE OrderDetails
(
  OrderDetailId INT IDENTITY (1, 1) NOT NULL,
  OrderId INT NOT NULL,
....
  CONSTRAINT OrderDetails_PK PRIMARY KEY (OrderDetailId)
)

По-моему, между этими таблицами должна быть связь внешним ключом между столбцами: Orders.OrderId -> OrderDetails.OrderId.
Но мы внешние ключи решили не использовать.
Что должно быть в слое бизнес-логики для того, чтобы запрос на вставку строки в OrderDetails не привел к нарушению ссылочной целостности?
Я правильно понимаю, что вместо этого:
INSERT INTO OrderDetails (OrderId, ...) VALUES (123, ...)

надо сделать что-то вроде этого:
IF NOT EXISTS (SELECT 1 FROM Orders WHERE OrderId = 123)
  RAISERROR('Нельзя нарушать ссылочную целостность', 16, 1)
ELSE
  INSERT INTO OrderDetails (OrderId, ...) VALUES (123, ...)

?
Ну, само собой, это все надо выполнить с нужным уровнем изоляции и наложением блокировки на выбранную в Order строку, чтобы между SELECT-ом и INSERT-ом другой пользователь эту строку не стер.
Если я понял правильно, то ИМХО быстрее отработает с внешним ключом...

LSV
А при различных ручных манипуляциях с данными часто приходится кратковременно и осознанно нарушать некую логику.
Изредка возможна ситуация, что сначала вставляются строки, а затем шапка.

А можно пример такой ситуации? Для меня это как-то диковато...

LSV
Или импорт из сырого источника, где логика уже изначально нарушена.

Ну в этом случае данные, которые надо загрузить в базу, просто некорректны с точки зрения модели данных бизнес-логики.
Я таких случаях в той же базе делаю отдельные таблицы для первоначальной (черновой) загрузки таких данных (может быть, не нормализованные и, да, может быть, без внешних ключей). Этакая маленькая свалка данных в базе данных. Но потом пользователю через интерфейс программы все равно приходится наводить порядок и перегонять эти данные в основные таблицы базы, в которых уже есть внешние ключи.
Все-таки просто загрузить данные в базу - мало. Главное как их потом можно будет использовать: строить отчеты или производить расчеты. А люди, которые пишут аналитические запросы, в праве рассчитывать на то, что данные в базе корректны. И "потерянных" строк в Detail-таблицах не будет. Я не прав?

LSV
Нарушение логики ФК всегда можно обнаружить и правильно отреагировать (н-р заново создать шапку или удалить/переместить осиротелые строки)

Как ты создашь заново строку в таблице Orders??? Откуда ты возьмешь ее реквизиты (номер, дату, КлиентId и пр.)? Заставишь пользователя заносить с бумаги?
3 авг 17, 12:25    [20697535]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
LSV
Member

Откуда: Киев
Сообщений: 29967
А можно пример такой ситуации? Для меня это как-то диковато...
Всё потому что Вы мало работали с данными. Это пройдет... :)


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

stomsky
Как ты создашь заново строку в таблице Orders??? Откуда ты возьмешь ее реквизиты (номер, дату, КлиентId и пр.)? Заставишь пользователя заносить с бумаги?
Не нужно проецировать проблему на конкретный случай. Мы обсуждаем подход, а не ордера.
Допустим я "просто знаю", что эта строка принадлежит клиенту ХХХ. :)
Можно штатно создать пустой документ и вставить ссылку на шапку в сиротской строке.
Кстати заново заносить с бумаги тоже приходилось. :)

Кароч есть масса случаев, когда приходится работать с несогласованными данными.
Лучше иметь поврежденные данные (кот. вероятно можно поправить), чем вообще ничего не иметь, кроме кучи ошибок вставки.
Удалить их всегда успеется.

Констрайнты не универсальны. Сегодня это ссылка на единственную таблицу. Завтра логика потребует сделать сложный ключ и сделать ссылку на разные таблицы (тип + ключ). Или вдруг потребуется запретить наличие ссылки на строку, у кот. сумма недостаточна или "тип" не тот.

Ниодна тиражная ERP система не использует ФК. И это абсолютно правильно для постоянно эволюционирующих систем.

Все равно нравятся констрайнты ? ОК. Используй их.
3 авг 17, 13:09    [20697663]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
buven
Member

Откуда:
Сообщений: 747
mr_max,
LSV
Ниодна тиражная ERP система не использует ФК. И это абсолютно правильно для постоянно эволюционирующих систем.

+1
Простой кейс:
Есть таблица сделок, есть в ней поле ID контрагента, у контрагента есть ссылка на справочник сегментов и т.д.
И таких полей у вас много за 30 с разной глубиной.
И предположим у вас распух EndOfDay. Вы точно определили, что дело не в связанных со сделками дынных, а в их количестве.
И у вас нет специалиста по производительности. Нужно отдавать анализ на строну.
Если у вас везде присутствует FK - вам придется отдавать, помимо таблицы сделок, еще и всю справочную информацию и рассказывать в какой последовательности заносить данные (пусть по каким то причинам бэкап отдать вы не можете).
Если ФК нет и целостность вы обеспечиваете на стороне клиента - вперед и с песней без всей этой гирлянды справочных данных.
3 авг 17, 14:06    [20697886]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
982183
Member

Откуда:
Сообщений: 929
LSV
Кароч есть масса случаев, когда приходится работать с несогласованными данными.

Масса.

LSV
Лучше иметь поврежденные данные (кот. вероятно можно поправить), чем вообще ничего не иметь, кроме кучи ошибок вставки.

А тут есть варианты.
Я бы сначала проверил данные на наличие в справочниках, правильное импортировал, а неправильные отправил бы в обработку.
Чем мучаться потом с корректировкой в рабочей базе.
3 авг 17, 14:09    [20697898]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
stomsky
Member

Откуда: Волгоград
Сообщений: 124
LSV
Кароч есть масса случаев, когда приходится работать с несогласованными данными.
Лучше иметь поврежденные данные (кот. вероятно можно поправить), чем вообще ничего не иметь, кроме кучи ошибок вставки. Удалить их всегда успеется.

Т.е. когда надо позволить иметь бардак в базе данных (хотя бы кратковременно)? :)
Ну тогда, конечно, возразить нечего :)

LSV
Ни одна тиражная ERP система не использует ФК. И это абсолютно правильно для постоянно эволюционирующих систем.

Хорошо, при должной прямоте рук разработчиков и достаточном их количестве без FOREIGN KEY обойтись можно. Можно даже без уникальных первичных ключей обойтись. Обычных индексов одних наделать и нормально. Но это, по-моему, из области: "у нас такая большая и богатая контора, что мы можем позволить себе разработать свою СУБД (свой ORM, свой Web-сервер и пр.)". На этом сайте реально все работают в таких конторах?
Чтобы отказаться от FOREIGN KEY в промышленной СУБД необходимо между нею (СУБД) и клиентом (написанным не тобой) воздвигнуть стену из сервисов доступа к базе. И обязать клиента модифицировать БД только посредствам этих сервисов.

LSV
Все равно нравятся констрайнты ? ОК. Используй их.

Договорились. :)
Я только за то, чтобы после того, как на вопрос "нужны ли констрейнты" ответить "нет", все-таки добавить "но в этом случае ты рискуешь... и потому тебе придется ...".
3 авг 17, 14:31    [20697965]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
Бредятина
Member

Откуда: Москва
Сообщений: 1654
mr_max
Прописывать на уровне бд или это старый век?
__________________________________________________________________
THE TRUTH IS OUT THERE

Вы, вероятно, говорите о "реляционной модели данных". В ней никаких связей нет, и прописать то, чего нет,
"на уровне БД" у Вас не получится.
Вероятно, Вы спрашиваете нужно ли ограничения целостности поддерживать на стороне БД, или их можно
поддерживать на стороне приложения. Чем больше ОЦ Вы будете поддерживать на стороне БД, тем качественнее Ваше приложение.
3 авг 17, 14:43    [20698030]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
LSV
Member

Откуда: Киев
Сообщений: 29967
982183
А тут есть варианты.
Я бы сначала проверил данные на наличие в справочниках, правильное импортировал, а неправильные отправил бы в обработку.
Чем мучаться потом с корректировкой в рабочей базе.
Сразу видно, что товарисч мало работал с данными... :)
Импортируете неск. разных тхт-файлов. Вроде бы нормальных. Ну отправьте их сначала "на обработку", ога....
Куда именно их отправить ? Как обрабатывать ?
Особенно, если импорт делается интеллектуально, т.е. не все данные реально импортируются в БД (допустим часть из них уже в базе есть).

зы: Я вообще за то, чтоб импорт делать только специальным механизмом, кот. умеет многократно проверить вводимые данные.
Да, это работает медленно. Это трудоёмко в создании, но за то данные будут надежными, а ошибки информативными.

зыы: у меня есть режим т.н. "тестового импорта", когда делаются все возможные проверки, кроме физической вставки (хранимая процедура).


ИСЧО РАЗ: Нравятся констрайнты - ОК.
3 авг 17, 15:07    [20698126]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
Очень лысый
Member

Откуда: БОМЖ
Сообщений: 478
Прикладные разработчики часто выдают разные гениальные идеи типа "СУБД разрабатывали лохи, щас мы тут целостность данных будем приложением проверять, да и вообще нафиг эту целостность проверять - будет быстрее работать". Каждый обязательно заново изобретёт EAV и удивится, как это эти старые пердуны за 50 лет до такой классной вещи не додумались. И нормализация не нужна: надо всё в одну таблицу и ведь как классно будет: никаких тебе джойнов, всё будет классно и быстро.
Если по теме, то ответ здесь очень простой: если нужен контроль целостности - нужны констрейнты, не нужен - не нужны.
3 авг 17, 15:22    [20698222]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
LSV
Member

Откуда: Киев
Сообщений: 29967
Очень лысый
Если по теме, то ответ здесь очень простой: если нужен контроль целостности - нужны констрейнты, не нужен - не нужны.
Ответ дилетантский. :)
Констрейнты не в состоянии обеспечить целостность бизнес-логики. Только малую ее часть.
Поэтому они почти никогда не нужны. Целостность обеспечивают другими средствами.
Удаление/вставка записи в БД это всегда сложный бизнес-процесс. Его нельзя применять в лоб. Для этого делают сложные процедуры, которые много чего делают, прежде чем удалить/вставить что-то. Поэтому польза от констрайнт = 1%.

Повторю: ниодна ERP-система не использует констрейнты.
3 авг 17, 15:55    [20698410]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4213
LSV
Тот, кто настаивает на использовании FOREIGN KEY просто мало работал с реальными данными. :)


FOREIGN KEY вообще никак не мешают работы с данными.
От слова вообще.

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

Зато это один из инструментов достижения ACID.

Так что правильно заметили.
Если вам не нужны FK, то лучше брать NoSQL.
Это будет быстрее и проще. :-)
3 авг 17, 16:12    [20698486]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
LSV
Member

Откуда: Киев
Сообщений: 29967
FOREIGN KEY вообще никак не мешают работы с данными.
Кому как. Я тоже когда-то давно так думал.

В таком случае для чего они нужны ?
Мешают удалять ? Дык есть простой рецепт: А ты не удаляй. :)

Если "привести к приемлемому виду, а потом правильно разложить по таблицам". ОК. А тут какую роль играют констрайнты, если все в приемлимом виде ?

зы: никто внятной их нужности так и не привёл. Ждёмс...
3 авг 17, 16:29    [20698549]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
stomsky
Member

Откуда: Волгоград
Сообщений: 124
LSV
зы: никто внятной их нужности так и не привёл. Ждёмс...

Лично для меня тут довод один: это еще одна (да, не совершенная, но чертовски эффективная "в пределах своей компетенции") линия защиты от:
1. Своих же собственных ошибок в коде, содержащем логику работы с БД.
2. Ошибок в коде других (написанных не мной) клиентов, содержащих логику работы с БД.
Если ты уверен в своей непогрешимости, то аплодирую стоя...
3 авг 17, 16:44    [20698592]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
LSV
Member

Откуда: Киев
Сообщений: 29967
stomsky
LSV
зы: никто внятной их нужности так и не привёл. Ждёмс...

Лично для меня тут довод один: это еще одна (да, не совершенная, но чертовски эффективная "в пределах своей компетенции") линия защиты от:
1. Своих же собственных ошибок в коде, содержащем логику работы с БД.
2. Ошибок в коде других (написанных не мной) клиентов, содержащих логику работы с БД.
Если ты уверен в своей непогрешимости, то аплодирую стоя...
Я вообще шапки никогда не удаляю. Для логического удаления есть спец. поле.
Абсолютно все удаления (в т.ч. логические) делаются соотв.процедурами, кот. делают много бизнес-проверок с внятными ответами на ошибки. Поэтому случайно удалить важную инфу невозможно.
3 авг 17, 16:58    [20698650]     Ответить | Цитировать Сообщить модератору
 Re: Нужно ли связи в таблицах в sql  [new]
stomsky
Member

Откуда: Волгоград
Сообщений: 124
LSV
Абсолютно все удаления (в т.ч. логические) делаются соотв.процедурами, кот. делают много бизнес-проверок с внятными ответами на ошибки. Поэтому случайно удалить важную инфу невозможно.

Т.е. на каждую сущность (читай таблицу) - отдельная процедура "Delete_<Entity>"?
3 авг 17, 17:12    [20698689]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
Все форумы / Проектирование БД Ответить