сфьщ Подскажите, как правильно спроектировать БД.Сразу скажу что правильно проектируется БД только для определенного задания. То есть КАМАЗ совершенно правильно спроектирован для перевозки грузов, но совершенно неправильно для поездок на работу и с работы.

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

например

Каменюка
Каменюка обыкновенная
Каменюка необыкновенная
Каменюка красивая

сфьщ Вопрос такой - как технически организовать (или реорганизовать) эту таблицу, чтоб обеспечить целостность.Целостность чего вы обеспечиваете? Поясню - в какой момент база должна выдать ошибку чтобы не дать вставить/поменять/удалить данные. То бишь в случае с примером выше мы не можем удалить запись Каменюка если от нее есть потомки.
авторДобавить еще одно поле и сделать его FK на id нельзя, не позволяют условия.Почему? Это как раз классическое решение - хотя и не единственное. Убрать поле status, заменить его на parent_id и если оно null - значит это разновидность, а не отдельный вид.

сфьщ Я склоняюсь к варианту:
- Сделать еще одну таблицу вроде - MTF (stone_id int,form_id int)Опять же чего вы хотите добится.

Сколько уровней в вашей иерархии?
Каменюка
Каменюка обыкновенная
Каменюка обыкновенная с дырочкой

Есть ли предел (офицально утвержденный) для максимума иерархий?

Можете почитать про Деревья в SQL

сфьщ Потому, что несколько , как вы пишете, "предков" может быть для одного "потомка".То бишь у вас нифига не дерево, а совсем даже граф. Тогда ваше решение
stones - узлы графа
MTF - дуги графа


имеет место быть.
сфьщ Если б существовал какой-нибудь идиоматический вариант, когда при удалении записи "Каменюка", все связанные с ней записи в таблице MTF удалялись, или при удалении записи "Каменюка рудная" все связанные с ней записи в MTF тоже удалялись
Если вы пропишите on delete cascade на ограничение, то при удалении узла все ссылки на него и/или от него автоматически удалятся. Если логика не столь однозначна - пишите триггеры.
сфьщ и при всем при этом записи в MTF были уникальны (как если бы был составной PK из stone_id,form_id) - я б был рад. И что вам мешает объявить такой первичный ключ?

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