>Чтобы спроектировать грамотную БД
>не надо знать характер данных, они вообще могут быть любые. Главное
>данные систематизировать, вывести связи (1:1, 1:М, это примерно сюда) и понять Вы сами себе противоречите. Как будете выводить связи если не знаете что за данные в БД?
Собственно за отношения (1:1, 1:М) я и говорил.
>Не могу понять логику вашего высказывания. Почему не может быть ОК, если
>эти поля заполняются не все и не каждый раз? Ошибка проектирования
>(и то, с точки зрения дальнейшей поддержки БД живыми человеками) здесь
>может заключаться только в некорректном именовании столбцов таблицы - сменится админ
>БД и будет неделю выяснять что именно хранится в name1, name2,
>name3...
Логика тут одна - чем меньше пустых полей тем лучьше. Но здесь, главное преимущество, что снимается ограничение на количество дополнительных полей. Хочешь вставляй 1 поле, хочешь 6 или 106. В исходном варианте не больше 6.
>Очень спорно. А если "вдруг" вот уже как пару лет не настает?
>А join-ы до сих пор с пустой таблицей работают. А зачем
>join-ы? А вдруг в тех двух таблицах внезапно появятся данные... Обычно,
>если "вдруг" настает и нужно хранить доп. данные, делают ALTER TABLE
>или создают новую таблицу. Да и выделять одному свойству сущности целую
>таблицу...
Нступает "вдруг", вы делаете ALTER TABLE и добываляете еще поле (или несколько). Потом еще "вдруг", опять ALTER TABLE и таблица становится еще шире. Так может сразу выделить в отдельную таблицу? Почему бы и нет. К тому же после каждого ALTER TABLE придется корректировать скрипты.
>[оверквотинг удален]
>Может я примерно и понял замысел тех советов, но не понял их
>смысл. Если вы избавляетесь от лишних полей в основной таблице, зачем
>поле id в дополнительной? Оно вам там ничего уникально не сыдентифицирует
>и с ним вы ничего осмысленного не получите. Если в основной
>таблице вашими методами вы избавились от name1, name2, name3 и таких
>же description, то напр, запрос вида "обнови второе имя у сущности
>с id=999" выполнить не получится. И зачем мне еще кучу join-ов
>с запросом типа "хочу все знать о сущности с id=999"? А
>если в будущем добавятся поля subname1, subname2, то мне нужно будет
>перелопатить все исходники и поменять такой запрос с учетом новых полей?
Избавиться от лишних полей не самоцель. В исходной таблице идут name1, name2, name3. Вы точно знаете что их порядок не имеет значение? Поля id нужны для сортировки. Без них (если нужно) в точном порядке вывести значения будет нельзя. А как внести правку? А удалить?
А на счет скоращения количества полей, то согласитесь, что довольно существенно поменять хотя бы одно поле varchar(999) на одно int.
>[оверквотинг удален]
>вообще кошернее смотреться будет: вместо ... JOIN b on (a.id=b.parent_id) вы
>напишете ... JOIN b using(id). А те субд, что умеют NATURAL
>JOIN, так вообще сказка: ... NATURAL JOIN b. Согласитесь, удобнее.
>По большому счету, это мое утверждение спорно, но лишь в том случае,
>когда на свет вылазят защитники принципа "имя таблицы не должно дублироваться
>в именах столбцов", напр. "столбцы с айди в любой таблице должны
>называться id". Определенный смысл в этом есть ("..where product.cost < package.cost.."),
>но такой принцип не канает в случаях, когда в таблице есть
>связь 1:1, напр. в таблице "сотрудник" придется заводить "отдел_id", т.к. поле
>"id" - это PK самой таблицы.
Соглашусь что утверждение спорно :)
Дело привычки по большому счету
>Наличие таких полей ни о чем однозначно не говорит. Оно может как
>бы намекать нам на то, что создатель БД новичок, либо ему
>было лень дать нормальные имена, либо что таблица будет использоваться как
>тестовая минут -дцать, а потом ее дропнут.
А однозначно я ничего не утверждал. Более того - говорил что нужно знать что будет храниться. Если там будут храниться длина/ширина/высота и т.п. и называться типа name1, name2,... потому что "ему было лень дать нормальные имена" то ничего менять не надо.
>Ну а если вы тотальный рационализатор и стремитесь к организации БД так,
>чтобы любая новая запись в таблицу заполняла _все_ поля, то... фиговый
>вы "запроектировщик" баз без "дырявых таблиц".
>Кстати, а вы NULL считаете значением?)
Я не " тотальный рационализатор", но иногда вижу как лучше. И не надо кидаться в крайности обзывая меня "фиговый вы "запроектировщик". Фраза "дырявые таблицы" придумана не мной и, очевидно, не просто так.
>зы. Сорри, если обидел. Настроение чего-то какое-то такое...))
А! Так это чтобы дух отвести?
Кошке привет!
