А что не модны сейчас foreign key, etc на уровне БД ?

не ленятся, а не умеют

Как связаны ORM и неиспользование FK?

По моему современные кодеры настолько увязли в своих ORM, что даже ленятся связи делать на уровне БД.

Откуда такая информация?

Современные orm эмулируют на своём уровне эти связи

Ну раз ОРм делает, то в чем проблема?

fk нормально не работают при горизонтальном масштабировании, при работе с k-v. А так как в моде именно хайлоад, считается что ФК фообще не нужны, и целостность то что называется eventual.

Ты не перепутал с nosql бд ?

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

Foreign Key умирает как часть технологии реляционных СУБД. Это факт. Ибо избыточна и хулиганит бритву оккама. MySQL тут со своими InnoDB потугами выглядит забавно.

Вангую так же смерть триггеров и хранимок.

А в некоторых проектах опенстека отсутствие Fk — осознанный выбор.

Обоснуй

Они плохо вписываются в ORM и вообще плохо себя чувствуют в MVC-парадигме.

Напрямую тоже можно. Ну а совместимость ОРм между собой - тут ничего не сделаешь.

Все ОРм поддерживают фк (мы же о рсубд). В чем проблема то?

Поддерживают скорее всего на уровне запросов генерят. Штук 5 запросов на один fk. Разве это быстрее будет работать чем fk в бд?

Это тебе какие-то говно ОРм попадались. Кстати где так сделано?

кодеру вообще дела не должно быть до каких-то там кеев - его дело crud и желательно БД-независимо. А бидеинженерам на ваши orm пофигу в любом случае

FK вообще плохо себя чувствуют в MVC-парадигме.

Ахаха.

Ну так это все очень сильно связано между собой. Можно и из mysql сделать nosql, если не использовать фк и джойны, и делать выборки только по пк. Во многих случаях будет ничем не хуже. Подозреваю, что отсутствие ФК в схеме это задел на горизонтальное масштабирование.

Штук 5 запросов на один fk.

Что за ужас, не драматизируйте. Назовите конкретную ORM, где вы это видели?
К слову говоря, определенные накладные расходы есть и при использовании FK (правда такие копеечные, что скорее всего вы даже их не заметите и на длинных бенчах), но адекватные оптимизаторы получают нехилое преимущество при составлении плана для «кривых» запросов. Посмотрите вот эти тесты:
http://www.scarydba.com/2010/11/22/do-foreign-key-constraints-help-performance/
Кайт Томас отвечая на вопрос в Effective Oracle by Design

Are the consultants who are advising getting rid of the keys paid by line of code?

сказал следующее, цитирую:

This could be true - the more they write, the more they make, the more they have to maintain, and the jmore they have to debug. As the earlier example of auditing showed, sometimes you can do in one line of code that uses a database feature what might take dozens or hundreds of lines of code otherwise. If the database does something, odds are that it does it better, faster, and cheaper than you could do it yourself.

Лично я с ним полностью согласен. Лучше довериться нативному решению, которое, кстати, в ряде случаев может дать заметный выигрыш. Что же касается ORM — это в основном надуманные проблемы, особенно связанные со сменой db. Скажите, в реальной жизни много ли вы видели готовых проектов меняющих db после нескольких лет успешного использования? Не спорю, такое возможно, но эти исключения — ужасные ошибки молодости, вот это все...

По моему современные кодеры настолько увязли в своих ORM, что даже ленятся связи делать на уровне БД.

По-моему как раз для избавления от ненужной работы и придумали ORM.

peewee с postgresql реализует внешний ключ средствами postgresql. Что не так?

1. Потому что это нифига не прозрачно.
2. Вот недавно была проблема: берется бд, дампится структура, заливается в тестовую бд, которая для каждого разраба своя, типа dbname_developerlogin. Фк при этом смотрит на таблицу в оригинальной бд. Как результат ловим кучу непонятных паданий тестов.

Скажите, в реальной жизни много ли вы видели готовых проектов меняющих db после нескольких лет успешного использования?

видел не сменяющие, а поддерживающие паралельно
на ум пришел gitlab: там mysql or postgres

Это то, что ты сам придумал, и еще пытаешься других в этом убедить.

Вот недавно была проблема: берется бд, дампится структура, заливается в тестовую бд, которая для каждого разраба своя, типа dbname_developerlogin. Фк при этом смотрит на таблицу в оригинальной бд

Думаю, кака цитата больше подходит случаю - эта или эта

Второй пункт - продолжение первого: нифига не прозрачно с точки зрения кода.

Что за ужас, не драматизируйте. Назовите конкретную ORM, где вы это видели?

Django удаление по ключу зависимых таблиц

при больших нагрузках половина запросов заменяется в любом ORM на «оптимизированные под коркретную БД» и смена БД там уже не получится.

Хм... а ты не из этих неотроглодитов, которые считают, что все проверки целостности должны выполняться приложением?

формошлепов пустили к биде

у формошлепов ниработаит

форенкеи гамно!!!1111

Приложению должно быть наплевать с высокой колокольни на то что находится по ту сторону драйвера бд.

Я не спрашивал об этом, но всё равно спасибо за ценное мнение.

Нагуглил, будто джанга ставит no-action на удаление, и сама рулит зависимостями. Ну жесть, что тут сказать :) Ну а если ты поставишь cascade в базе ручками, это завалит джангу? Вообщем это очередная конкретная проблема конкретного фрейма. Я уверен — спецы по ней тебе сейчас подскажут как эту проблему разрулить. Я сам пойду погуглю насчет этого вопроса.

а какое к этому имеет отношение ваше неумение базу сдампить нормально?

Скажите, в реальной жизни много ли вы видели готовых проектов меняющих db после нескольких лет успешного использования?

мы тут на одном из самых нагруженных проектов с частичным даунтаймом (R/O на пару минут) переходили mysql->postgres. Три месяца ресерча, безумные скрипты для починки легаси-неконсистентностей и патчи на tungsten. В общем, задачка реализуемая, но еще раз это проделать - ну нахер.

Ну а если ты поставишь cascade в базе ручками, это завалит джангу?

south даже сам умеет предлагать cascade и потом корректно хэндлит результат. Но упасть может :)

Ну а если ты поставишь cascade в базе ручками, это завалит джангу?

Там проблема в том что это хрен отключишь - т е чтобы отключить «удаление с помощью ORM и включить удаление средствами БД» нужно ставить костыль. ВОт такое отношение создателей этого ORM к БД.

но как, Карл, как? Хибернейт сам расставляет FK, в Active Record емнип там одним параметром делается

Это и был ответ на твой вопрос.

особенно если драйвер БД не умеет транзакции, и тут тебе написать бы CAS loop, но тебе наплевать с высокой колокольни xD

особенно если драйвер БД не умеет транзакции

То это совсем печально.

Хибернейт сам расставляет FK,

хибер говно, потому что путает нужные типы данных и т.п. + не умеет апдейт схемы, в итоге приходится делать схему руками + flydb или liquibase. Ну а руками каждый делает как может, даже dba буржуйские, сам неоднократно убеждался.

ВОт такое отношение создателей этого ORM к БД.

Погуглил. Сначала нашел более менее адекватное объяснение целенаправленного использования именно эмуляции.

Django emulates ON DELETE CASCADE in Python — that's why is doesnt need it set on the database tables. In fact, setting RESTRICT might even make sense, since it means that you can't accidentally delete any related objects without being warned about it in the admin.

Подумал что не могли пользователи отказаться от нативных решений, начал гуглить тикеты, и наткнулся на этот
https://code.djangoproject.com/ticket/21961
После кривых патчей можно будет юзать?

...
    related = models.ForeignKey(Related, on_delete=DB_CASCADE)
...

нужно ставить костыль

Это, конечно же, печально.

В общем, задачка реализуемая, но еще раз это проделать - ну нахер.

Вот вот. Это ж

Три месяца ресерча, безумные скрипты для починки легаси-неконсистентностей и патчи на tungsten.

убиться просто можно. Хотя сам факт mysql -> postgres не может не радовать :)

За другие ORM не скажу, но ActiveRecord делает fk средствами базы (проверено на мускуле и постгре).

ActiveRecord - это паттерн, в Django вон тоже ActiveRecord, а в нормальные fk не умеет.

Ну, мы же и так в курсе, что джанга не нужна :)

у вас ДБА рукожопый

Это в какой бд так? В postgresql вроде бы можно только между схемами а не между бд ?