javajdbcЖека блин,

16909873 ...и ссылки внутри этого ФАКа...
javajdbc , да вы, извините, латентный терапевт

javajdbcво избежание конфуза
Да понятно, что на SQL можно сделать очень многое, но...
Но зачем учить плохому, рушить основы реляционных баз, а затем мужественно, я бы даже сказал, героически, преодолевать трудности плохого проектирования? Не проще ли сразу научить хорошему, доброму, вечному процессу нормализации баз данных?

javajdbc...к окулисту! иначе спор ни о чем.
я умею разбирать строки на элементы, разными способами, могу сформировать запрос на стороне клиента, могу соорудить DSQL - в этом смысле вы совершенно напрасно аппелируете к FAQу.

Речь совсем не об этом.

Можете просто сказать, считаете ли вы целесообразным первый шаг нормализации реляционных данных (1НФ) или нет?

javajdbcчитайте:

8434456
Да читал я это, еще когда интересовался отличиями в разборе строк между разными СУБД

Вы на вопрос-то ответьте, не юля
Не верится, что проще троллинг включить, чем ответить... Но видимо придется

miksoft, суть, кмк, проста.

Средствами MySQL имеется возможность разобрать поле, содержащее FK к другой таблице, и на эту тему составлен FAQ
Уважаемый javajdbc с упорством окулиста-бюджетника пытается втереть мне, что в этом FAQе проблема решена, но он не считает такую схему правильной. (Ето плохой дезайн, не делайте так. Дальнейшее обсуждение расчитано
только на вариант когда такой плохой дезайн уже есть и исправить нельзя)

Однако при наличии решения проблемы у изучающих SQL желание что-то переделывать начисто пропадает. В результате через какое-то время мы видим нечто уже совсем странное: foreign key set

Поэтому если уж вы даете в FAQ частное решение проблемы связывания - дайте и частное решение проблемы контроля целостности...

Или не давайте вообще никакого решения, скажите честно, что этим занимаются постреляционные СУБД, к каковым MySQL, разумеется, не относится, и порекомендуйте, например, пользоваться той же InterSystems Cache

А при отсутствии желания/возможности использовать постреляционные СУБД - будьте любезны соблюдать 1НФ

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

javajdbc...ок, проехали...опс...

Нет уж, пожалуйста реализуйте список FK с поддержкой целостности! :)

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

miksoftCygapb-007Или хотя бы пропишите большими красными буквами в FAQСобственно говоря, Вам это тоже ничего не мешает сделать.Ок

Хранение в реляционных СУБД первичных ключей в виде списка
нарушает принципы организации реляционных баз данных ( http://www.mstu.edu.ru/study/materials/zelenkov/ch_4_2.html]1НФ )

Но самое главное - такой способ хранения ссылок на другие таблицы ( список Foreign Key в текстовом поле )
не может обеспечить ссылочной целостности данных ,

а значит - в значительной мере
теряется достоверность хранимой информации

tanglirCygapb-007такой способ хранения ссылок на другие таблицы ( список Foreign Key в текстовом поле )
не может обеспечить ссылочной целостности данных точно? а если триггер написать? Так я ж попросил реализовать - в ответ тишина...

А триггер будет писать тот, как я понял, кто хранит FK в строке?