Не стану спорить ибо это затянется. Скажу лишь что в MySQL нет контроля ссылочной целостности (по крайней мере для MyISAM) и это не мешает быть этой СУБД популярной. Наверное это о многом говорит.
Ссылку не дам. Внутреннюю реализацию там все равно не видно а расценят как пиар проекта. Не к чему здесь.
Я потом позже расскажу как обрабатывать разнотипные связи. В двух словах многие не поймут, тут подробно нужно рассказывать на примерах, а времени сейчас нет.
Проблем быть не может, потому что для удаления объектов используется гарбиджколлектор. При удалении объекта, на самом деле объект из таблицы не удаляется, а удаляется лишь ссылка на него из твблицы GUID. Гарбиджколлектор (обычный джоб например) периодически удаляет объекты, на которые никто не ссылается. Само наличие лишних записей в БД не критично, это просто мусор который никому не мешает.
Я и не призываю использовать эту схему везде. Я в статье упомянул, что даже в системе выполненной по этой схеме, некоторые части реализованы по классической. Впрочем каждый имеет право на свое мнение. Некоторые до сих пор ООП не признают, и с радостью вам докажут чем ООП плох.
Кстати насчет "каждый должен через это пройти"
Опыт проектирования баз данных у меня достаточный, что бы отличить хорошее от плохого. Нужно понимать, что в данном случае БД это лишь место хранения связей объектов, для реализации паттерна "компоновщик". Вообще говоря, хранить связи можно где угодно, например в xml, просто в данном случае выбрана СУБД.
По поводу типа связей, этот вопрос так же решен, но другим способом. Не хочется углубляться сейчас в подробности.
Насчет второго замечания, не согласен. Связи ограничивать не так уж необходимо. Но если так уж хочется, можно этот контроль реализовать программно, например с помощью файла конфигурации. Пока такой необходимости не было.
Наверное SQL? Наверное стоит перед переносом подредактировать статью, литературный стиль, орфографию. Писалось "по быстренькому", поэтому не уверен что все всем понятно. Давайте сначала обсудим, а там посмотрим.
Кстати, спасибо за ссылку :)
Я потом позже расскажу как обрабатывать разнотипные связи. В двух словах многие не поймут, тут подробно нужно рассказывать на примерах, а времени сейчас нет.
Опыт проектирования баз данных у меня достаточный, что бы отличить хорошее от плохого. Нужно понимать, что в данном случае БД это лишь место хранения связей объектов, для реализации паттерна "компоновщик". Вообще говоря, хранить связи можно где угодно, например в xml, просто в данном случае выбрана СУБД.
Насчет второго замечания, не согласен. Связи ограничивать не так уж необходимо. Но если так уж хочется, можно этот контроль реализовать программно, например с помощью файла конфигурации. Пока такой необходимости не было.