parser

Написать ответ на текущее сообщение

 

 
   команды управления поиском

если говорить про изготовление машины, то...

Misha v.3 15.08.2005 15:47

... огромный кузов класть в одну коробочку (даже разделенную перегородками) с гайками M3 - плохая идея.
Если не задумаваться что лежит в таблице (страны и т.д.), а назвать все переменными: все переменные имеют одинакаовй тип данных и способ описания, и используются по одному и тому же назначению.
пока мне не расскажут про все, что бывает в системе я не приступаю к проектированию БД. я ни разу не делал проектов где у города например есть только название. или где у продукта есть только название. полей у этих сущностей много и все остальные поля у них различны.

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

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

похоже все таки речь идет не о "всех сущностях в одной таблице", а о "всех _текстах_ в одной таблице". в этом случае я могу согласится что подобный подход имеет право на жисть (однако прежде, как я уже говорил, надо проанализировать исходную задачу), но тут все равно не должно быть PK. тексты должны иметь родительские ID + тип. т.е. запись в тех других таблицах со странами/продуктами обязана иметь записи, а сюда просто вынесены тексты (чтобы в случае добавления еще одного языка не делать alter 10 таблицам добавляя name_de, name_pl и т.д.).