Добрый вечер, господа профессионалы, я новичок в теме sql и

Баз Данных в общем.
Можно задать нескромный вопрос ?
Корректна ли таблица только из FK или так делать не надо?

Более чем.

Почему бы и нет, если логика того требует? Возможно, ещё Primary Key нужен. Но не всегда, надо структуру и объем данных смотреть.

Эээ... в смысле? Т.е. что Вы имеете в виду?

Если речь о реляционном проектировании, то PK нужен всегда, если что.

что вы здесь имеете в виду под FK?

Видел я и обратные примеры ) Но в целом да, нужно.

Только из вторичных ключей, что-то вроде таблицы, соединяющей остальные

Это примеры ошибок проектирования, не более того. ;) Т.е. создать-то можно много всего "интересного"... если не забывать принцип "write once and run away".

Да, это нормально (и вообще "классическая" таблица для many-to-many).

Понял, благодарю

Я всегда люблю приводить в пример одну довольно известную банковскую систему, в которой в бытность мою банкиром не было ни одного первичного и внешнего ключа. Индексы, правда, были, местами уникальные. И оно как-то даже работало )))

Плохо спроектированных систем и БД на практике очень много, к сожалению. И они как-то даже работают. ;)

И чо? Я всегда так делаю! (с)

Обычно они говорят "ключи - это же удар по перфомансу" 😊

Правильно говорят.

Да я и не спорю. Любое наведение порядка, в БД ли, в разработке - это несомненный удар по "перфомансу" )

А из-за ФК нет возможности вставить/удалить,отредактировать, например, разное. Было у меня такое, да...

Ну дык в этом вроде и смысл основной

Весь этот смысл идет лесом, когда в базу прилетает 10к записей, их нужно все разобрать и разбросать по таблицам без дублей. А главное: на все про все есть сотня миллисекунд. Первое что приходится делать - выбрасывать FK.

и поэтому во всех базах не нужны FK?

Может, стоит выбросить настолько "прекрасное" железо, а не FK? И не работать на "кофемолках" впредь? ;)

Что такое по сути FK? Это обычная проверка, не более. Причем проверка временами весьма затратная. Где в системе на каких этапах стоит проводить проверки - решать разработчику. Не нужно делать из этого панацею.

Да-да, я много раз слышал такие сказки. А вот [сколько бы то ни было длительно эксплуатируемых] систем, где такая проверка была не на этапе БД, и при этом без проблем со ссылками, как-то не видел.

панацею тут только вы делаете, когда говорите на основании сверхузкого кейса, что FK не нужны

(к тому же FK могут давать и перформанс бонусы в виду join elimination - хоть в постгресе это и не реализовано, вроде)

Да ладно)) Задумайтесь как реализована система у Visa или MasterCard когда карточку в банкомат вставлять будете))

Хмм... а при чём тут это? Обсуждалась конкретная тема, нет? Я имел в виду, что подобные constraints надёжно реализовать без поддержки СУБД практически невозможно — вот почему я назвал это "сказками".

Как раз таки когда нужно действительно надежно реализовать целостность, то СУБД вообще выбрасывается нафиг вместе с FK.

Странно. Я в основном видел, что обратные действия работают, а "выбрасывание" — почти никогда. О каких решениях / реализациях речь, подробнее?