Программирование, т. 8

 

ты рофлишь что ли?

 

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

 

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

 

 

и причем тут нахуй вообще 6 нормальная форма? нормальные формы не имеют никакого отношения к целостности базы, пиздец

 

1. это ты рофлишь чтоли. ты серьезно не понимаешь что можно без FK счастливо жить в большом количестве ситуаций?

2. я не понимаю почему отсутствие фк для тебя проблема. там лежит то что ты туда положил. в код ты в любом случае будешь смотреть чтобы понять что есть что.

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

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

4. так, а к чему нормальные формы имеют отношение?

 

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

2. потому что в код надо смотреть чтобы понять как данные обрабатываются. А не как выглядит структура этих данных. И они никогда не должны быть связаны. У тебя даже приложений может быть пару сотен штук, и им всем насрать на код, который написан в других приложениях. Целостность данных одна на всех, и ее никто не должен иметь возможности сломать.

3. ормки генерят не потому, что им это ничего не стоит, и там не надо ничего отключать. Ормки генерят потому что это их способ мапить таблицы на объекты, без ключей они тебе не могут ничего сами сгенерировать, тк никто в таком случае не знает, какие колонки содержат реально одно и то же. База вообще может быть пуста, ормке похуй, по ключам всё ясно сразу же, какие надо ссылки на другие объекты или вложенные коллекции где делать, в каком порядке добавлять, обновлять и сохранять данные. Да даже банально в контекст не надо вручную добавлять все зависимости. У тебя готовый граф объектов сформирован где-то, и тебе в контекст добавить нужно только его корень, и всё потом сохранится вместе. Либо наоборот ты добавляешь один объект и дальше пихаешь его по методам внутрь которым контекст даже не нужен, они просто заполняют содержимое по всем связям как им надо. Без ключей ты нихрена из этого как минимум автоматом не получишь и придется вручную создавать модель ормки не по модели базы, причем с риском наебаться, не говоря уже о том, что это никак не отслеживает изменения, происходящие в базе.

4. это уже даже не смешно. Ну может загугли и узнаешь, что нормальные формы внезапно отвечают за нормализацию, а не за целостность. За целостность отвечают только внешние ключи.

 

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

 

 

Ой прав) Я проект с чуваком пилили, так вот он сделал базу mysql на движке MyISAM (MyIsam какрас не поддерживает fk, в отличии от InnoDb с которой я обычно работаю) . Ну и че пилил проект как обычно, в миграциях прописывали fk , делали связи и тд. Проект с перерывами полтора года делали и вот буквально два дня назад я случайно заметил, что почему-то моя утилита для работы с бд как-то не так показывает поле которое должно быть фк. Начал копать и увидел что движек myisam используется)

 

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

 

 

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

 

ключи вообще никак не ограничивают получение данных, это не их забота, читай как хочешь. Они нужны для ПОДДЕРЖАНИЯ ЦЕЛОСТНОСТИ БАЗЫ ПРИ ЛЮБЫХ ИЗМЕНЕНИЯХ ДАННЫХ

пиздос, кому я тут вообще вопросы про дедлоки задавал

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

 

 

ты рофлишь что ли?

 

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

 

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

 

 

и причем тут нахуй вообще 6 нормальная форма? нормальные формы не имеют никакого отношения к целостности базы, пиздец

 

1. это ты рофлишь чтоли. ты серьезно не понимаешь что можно без FK счастливо жить в большом количестве ситуаций?

2. я не понимаю почему отсутствие фк для тебя проблема. там лежит то что ты туда положил. в код ты в любом случае будешь смотреть чтобы понять что есть что.

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

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

4. так, а к чему нормальные формы имеют отношение?

 

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

2. потому что в код надо смотреть чтобы понять как данные обрабатываются. А не как выглядит структура этих данных. И они никогда не должны быть связаны. У тебя даже приложений может быть пару сотен штук, и им всем насрать на код, который написан в других приложениях. Целостность данных одна на всех, и ее никто не должен иметь возможности сломать.

3. ормки генерят не потому, что им это ничего не стоит, и там не надо ничего отключать. Ормки генерят потому что это их способ мапить таблицы на объекты, без ключей они тебе не могут ничего сами сгенерировать, тк никто в таком случае не знает, какие колонки содержат реально одно и то же. База вообще может быть пуста, ормке похуй, по ключам всё ясно сразу же, какие надо ссылки на другие объекты или вложенные коллекции где делать, в каком порядке добавлять, обновлять и сохранять данные. Да даже банально в контекст не надо вручную добавлять все зависимости. У тебя готовый граф объектов сформирован где-то, и тебе в контекст добавить нужно только его корень, и всё потом сохранится вместе. Либо наоборот ты добавляешь один объект и дальше пихаешь его по методам внутрь которым контекст даже не нужен, они просто заполняют содержимое по всем связям как им надо. Без ключей ты нихрена из этого как минимум автоматом не получишь и придется вручную создавать модель ормки не по модели базы, причем с риском наебаться, не говоря уже о том, что это никак не отслеживает изменения, происходящие в базе.

 

4. это уже даже не смешно. Ну может загугли и узнаешь, что нормальные формы внезапно отвечают за нормализацию, а не за целостность. За целостность отвечают только внешние ключи.

 

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

мой проект сейчас - у нас 159 таблиц в довольно большом (по объему кода, логики и сущностей) и нагруженном приложении (далеко до хайлоада, но достаточно чтобы испытывать проблемы с производительность и оптимизировать ботлнеки) которое разрабатывалось уже 1.5 года, и полгода крутится в проде. где-то фк есть, где-то нету. живем без проблем.

2. для бд в которую доступ от нескольких приложение - бесспорно ФК и вообще централизация логики и правил внутри бд (по сути единственный источник истины) - это крайне эффективная практика

но как бы сейчас в пору микросервисов 1бд=1приложение и оно полный владелец базы данных

3. чето я не понял как схема бд пересекается с тем как работает орм. орм работает на основе заложенного в неё конфига. ты можешь дать ей любую схему с которой она способна работать. орм это вообще довольно примитивная вещь, которая маппит объекты в sql запросы и обратно. никакие ФК ей для этого не нужны от слова совсем. чтобы связать объекты она просто джойнит таблица по полям.

я если честно не понимаю что за магическая ОРМ такая в твоем представлении которая, как я понял с твоих слов, парсит схему базы данных и использует ФК для автоматического сохранения зависимых данных.

4. окей, пойдем на шаг дальше - для чего нужна нормализация?

ключи вообще никак не ограничивают получение данных, это не их забота, читай как хочешь. Они нужны для ПОДДЕРЖАНИЯ ЦЕЛОСТНОСТИ БАЗЫ ПРИ ЛЮБЫХ ИЗМЕНЕНИЯХ ДАННЫХ

пиздос, кому я тут вообще вопросы про дедлоки задавал

 

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

я не знаю, знаешь ли ты, но без индексов все будет работать...

просто медленно

а вот про pk мы недавно с коллегами разбирались.

в постгресе ты можешь создать таблицу без pk и работать с ней как обычно

ну и кант

объясни мне тогда как работают системы в которых нету ФК?

на монге, касандре, кафке, редисе?

без них же все пойдет по пиздец и вообще так нельзя..?

в постгресе ты можешь создать таблицу без pk и работать с ней как обычно

ещё можно айдишники писать в поле типа text, но нужно ли?

 

в постгресе ты можешь создать таблицу без pk и работать с ней как обычно

в постгресе? я думал так везде можно

ещё можно айдишники писать в поле типа text, но нужно ли?

 

ну я не говорю что ФК не нужны. я говорю (в противовес канту) о том что это не является обязательным условием

про айдишники - можно в поле текст хранить через запятую айдишники для связи one to  many. скорее конечно не стоит. но можно. и в некоторых ситуациях (гипотетических) даже придется 

объясни мне тогда как работают системы в которых нету ФК?

просто что так не стоит делать

так же как не стоит пользоваться языками с динамической типизацией

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

а я кстати ему предлагал на монгу мигрировать. нет фк = нет проблем

в системе у немцев на серваке нет форейн кин,

зато есть проверка в C# (на sql стороне) переменная @noReferences которая проверяет есть ли ссылки на этот айдишник в других таблицах (штук 5)

Если @noReferences = 1 то удаляется)))

пиздос, кому я тут вообще вопросы про дедлоки задавал

 

 

в постгресе ты можешь создать таблицу без pk и работать с ней как обычно

в постгресе? я думал так везде можно

ещё можно айдишники писать в поле типа text, но нужно ли?

 

в oracle же вроде так и делается с гуидами

Какие же вы все тут душные, шок просто.

 

 

в постгресе ты можешь создать таблицу без pk и работать с ней как обычно

в постгресе? я думал так везде можно

ещё можно айдишники писать в поле типа text, но нужно ли?

 

в oracle же вроде так и делается с гуидами

 

бывают бизнес ключи и технические ключи

бизнес ключ чаще всего нельзя записать в инт

и ваще какая разница, что ты число в условный варчар пишешь.

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

@@Kant

создай рядом такую же таблицу

дропни старую

и создай вьюху с именем старой таблицы на новую таблицу типа select * from blabla with (nolock)

вообще плюсую насчет фк, на последних нескольки проектах они если и были - то исключительно дизейблд (те их делали, что б можно было автоматом всякие юмл диаграммы выгружать), потому что фк, сюрприз-сюрприз, замедляют вставку\удаление (а в том же цаландо с его 4 000 таблиц ЕТЛ ночной и так трещал по швам и там урывали каждую долю производительности), вместо этого целостность данных была обеспечена в ETL + тестами

бывают бизнес ключи и технические ключи

бизнес ключ чаще всего нельзя записать в инт

Погоди-ка. Почему это guid/unquidentifier это int? Типа как datetime это два int внутри?

Погоди-ка. Почему это guid/unquidentifier это int? Типа как datetime это два int внутри?

прочитай как хранится нативный uuid в бд

правда вот у нас на проекте используются uuids не нативные - просто varchar(32)

Погоди-ка. Почему это guid/unquidentifier это int? Типа как datetime это два int внутри?

посмотри как они выглядят, там все символы это 0-9A-F, тоесть хекс

лень щас гуглить считать байты но думаю там будет до 16 байт, тоесть в бигинт поместится

Фронтэнд, который мы заслужили

Иногда при заполнении форм перетягиваю javascript:void(0) с кнопок