PaulWist

Владимир Максимов
Ты исходишь из предположения, что к СУБД всегда будет доступ из-вне приложения. Напрямую. Причем не с целью выборки данных, а именно с целью модификации данных.

Да, и это не предположение, а обьективная реальность.

Моя "упёртость" в этом вопросе "произрастает" из моего же опыта, я залезаю в чужие БД, в мои БД тоже залезают, если нет соответствующей "точки доступа" к данным (ХП), то самому приходится её писать, вот здесь защита от дурака в виде фич БД ставит последний рубеж.

Залезаешь в чужие БД именно с целью модификации? Ну, "безумству храбрых...". Я бы не рискнул. Именно по той причине, что далеко не всю логику можно реализовать через ХП. Да и бессмысленно это.

Я ведь говорю не о доступе "вообще", а о доступе с целью модификации. Вот именно эта ситуация совершенно недопустимая. А "защита от дурака" - это дать доступ только на чтение. Вьюшки, там, разные. Т.е. решается значительно более простыми средствами.

Владимир Максимов
Залезаешь в чужие БД именно с целью модификации? Ну, "безумству храбрых...". Я бы не рискнул. Именно по той причине, что далеко не всю логику можно реализовать через ХП. Да и бессмысленно это.
...

Да, не вижу здесь особого риска, как уже говорил, если есть точка доступа, обычная ХП с помощью которой разработчик сам модифицирует данные, я тоже через неё работаю и ко мне так же залезают, считаю это нормальным ходом (нами рассматриваема 1с через СОМ-интерфейс тоже позволяет это делать)

Если ХП нет, то пишешь свою (конечно же для этого надо достаточно хорошо знать саму бизнес логику и структуру данных, разработчик обычно говорит мне некогда, либо тебе надо ты и пиши, структуру БД я тебе дал )

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

Возможно так только у меня с моим "зоопарком".

Владимир Максимов
Я ведь говорю не о доступе "вообще", а о доступе с целью модификации. Вот именно эта ситуация совершенно недопустимая. А "защита от дурака" - это дать доступ только на чтение. Вьюшки, там, разные. Т.е. решается значительно более простыми средствами.

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

PaulWist
Возможно так только у меня с моим "зоопарком".

Скорее всего. Ты описываешь не вполне типичную ситуацию, когда с одной и той же базой данных напрямую работают принципиально разные приложения. Обычно все-таки ТАК не работают. Как правило, используют специальные программы - "переходники".

Например, уже упомянутый Com-интерфейс 1С. Это ведь вовсе не прямой доступ к данным. А именно доступ через программу. А уж эта программа и берет на себя труд отслеживания целостности данных.

Владимир Максимов
Скорее всего. Ты описываешь не вполне типичную ситуацию, когда с одной и той же базой данных напрямую работают принципиально разные приложения. Обычно все-таки ТАК не работают. Как правило, используют специальные программы - "переходники".

Например, уже упомянутый Com-интерфейс 1С. Это ведь вовсе не прямой доступ к данным. А именно доступ через программу. А уж эта программа и берет на себя труд отслеживания целостности данных.

Возможно, не типично.

Вот последний пример, есть модуль приёма заказов/счетов,... бизнес расширился, теперь требуется заносить данные через web, web-приблуду пишет другая контора, которая дёргает мои ХП ( действительно, не городить же им свою БД + импорт/экспорт, а мне не писать же СОМ-прослойку, что бы они тягали/модифицировали данные)

Вклинюсь между строк битвы гигантов(PaulWist и Владимир Максимов)
и отвечу Igor Korolyov.

Разумеется, 100% результат обеспечить в некоторых случаях нельзя, например после
падения метеорита на Землю.

GotFocus
Разумеется, 100% результат обеспечить в некоторых случаях нельзя, например после
падения метеорита на Землю.

Его невозможно гарантировать и при более вероятных событиях. Все никак не пойму что же Вы нам пытаетсь доказать-то? При ответе желатено учитывать, что мы тоже были маленькими, тоже писали свои затычки на все случаи жизни и т.д. И опыт работы у нас тоже не один год.

Речь шла не про катастрофы вселенского масштаба, а про то что банальнейший батник делающий архивацию обеспечивает ровно тот-же уровень защиты что и твоя мегасистема. Нормальная же (вменяемая, адекватная, есть ещё много слов) ПОЛИТИКА обеспечения информационной безопасности (не в части защиты от крадунов, а в части защиты от непреднамеренных потерь информации) - даст заведомо БОЛЬШИЙ эффект чем самая навороченная програмная система. При том политика включает целый спектр мер, включая аппаратное (тот самый RAID, бесперебойник и т.п.) и организационное обеспечение (тот самый администратор, пусть даже "приходящий", обучение юзеров не дёргать вилку из розетки...).
Политика основанная ТОЛЬКО на наличии мега-программы которая сама всё сделает - это нонсенс.
А раз так, то зачем тратить больше сил и времени на этот велосипед, чем минимально необходимо?
Вопросы восстановления данных из убитых табличек или их индексов, проверки корректности тех-же таблиц/индексов "на лету", это интересные теоретически (они всплывают периодически на форуме), но абсолютно бессмысленные практически вопросы. Просто потому что возникновение такого вопроса уже говорит о том что "в консерватории" не всё в порядке.
Как говорится в известной шутке (и это реально уже НЕ шутка), все администраторы делятся на 2 группы: те кто делает бэкапы, и те кто БУДЕТ делать бэкапы.
Всё прочее - от лукаваого.

PaulWist

GotFocus
Вот такой приём уже 15 лет успешно применяется мною, опровергая слова ребят
о его неправильности. Критерий истины - практика.
...

Дело в том, что как только надо будет упаковать таблицу (либо будет достигнут предел в 2Г, либо повысить селективность индекса, итп... видать Вы ещё этих границ не достигли), то сразу ссылочная целостность отвалится,... те решать проблему с первичным и внешним ключем всё равно придётся - это только вопрос времени.

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

С базой SQLLite я не знаком и что означает твоя фраза "по умолчанию внешние ключи выключены" - не понимаю. Поэтому начну с терминологии, чтобы все стороны однозначно понимали, о чем идет речь

Primary Key и Foreign Key физически представляют собой обычные поля таблицы в которых записывается код (идентификатор) записи

Primary Key - код записи текущей таблицы
Foreign Key - код записи другой (внешней, по отношению к текущей) таблицы

Поэтому включить/отключить Foreign Key невозможно "в принципе". Это же просто поле. Как ты его отключишь-то?

А то, что, скорее всего, ты подразумеваешь, называется "организация ссылочной целостности". Т.е. создание неких настроек/программ, которые следят за тем, чтобы взаимные ссылки между таблицами (которые и организуются при помощи PK/FK) были не противоречивыми

И вот тут возникает вопрос. А что означает "не противоречивыми"? Не противоречат чему? Ну, очевидно, неким правилам. Каким?

На этот вопрос каждое приложение отвечает по своему. В каждой базе данных эти правила могут быть свои. Обычно предлагается минимум 3 варианта

- Ignore - игнорировать. Ничего не делать - настройка по умолчанию
- Cascade - делать то же самое в подчиненной/главной таблице
- Restrict - запретить

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

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

Владимир Максимов
С базой SQLLite я не знаком

Не SQLLite, а SQLite. Исправь пожалуйста, заодно сообщи как редактировать сообщение на этом форуме(забыл, а может это невозможно)
Благодаря Cascade я и узнал, что ключи были отключены. Внешние ключи были созданы, но Cascade не работал.
Мне стало интересно, а что по этому поводу скажет товарищ Жюков GPT Chat, и я задал ему вопрос : "Какие преимущества от того, что в SQLite по-умолчанию отключена поддержка внешних ключей ?"
Его ответ

Цитата:

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

Более гибкий дизайн базы данных: Отключение поддержки внешних ключей также позволяет более гибкий дизайн базы данных, поскольку вы можете изменять структуру таблиц и отношений между ними без необходимости учитывать внешние ключи.

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

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

Я бы поправил иск. интеллект

Цитата:

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

.

GotFocus

Владимир Максимов
С базой SQLLite я не знаком

Не SQLLite, а SQLite. Исправь пожалуйста, заодно сообщи как редактировать сообщение на этом форуме(забыл, а может это невозможно)

Там же, где ты жмешь "Ответить" может быть пункт "Редактировать". Но он появляется только если на тему еще никто не ответил (или по времени?). Сейчас для меня это уже недоступно, поэтому исправить не могу Если только Джойсу писать (модератору). Но из-за такой мелочи, думаю, не стоит

GotFocus
Благодаря Cascade я и узнал, что ключи были отключены. Внешние ключи были созданы, но Cascade не работал.

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