>>данные систематизировать, вывести связи (1:1, 1:М, это примерно сюда) и понять
>
>Вы сами себе противоречите. Как будете выводить связи если не знаете что
>за данные в БД? Я как раз написал в том порядке, в котором надо действовать. Вывод связей - на втором месте, так что на этот момент данные уже у нас есть.
Но говоря про характер, это скорее похоже на вопрос админа "чего хранить будем" на задачу шефа "сделай мне БД ко вчера". Это вообще нулевой этап. Может быть данные такие будут, что их эффективно можно хранить в нереляционной БД. А там свои понятия могут быть, отличные от "сущность", "связь" и т.д.
>>Почему не может быть ОК, если эти поля заполняются не все и не каждый раз?
>Логика тут одна - чем меньше пустых полей тем лучьше. Но здесь,
>главное преимущество, что снимается ограничение на количество дополнительных полей.
> Хочешь вставляй 1 поле, хочешь 6 или 106. В исходном варианте не больше 6.
Эмм, может быть мы про разные типы СУБД говорим? Я про реляционные.
Почему чем меньше пустых значений, тем лучше? Лучше в каком плане? По скорости выборки? Планировщик лучше работает? Ну постройте индекс (если он будет полезен) по соответствующему полю...
Если вы говорите про ограничения кол-ва полей, то, видимо, держите в голове какую-то конкретную СУБД. У современных СУБД ограничения такого рода - огромные. На бурную фантазию хватит. Напр., для postgres8.4: кол-во строк в таблице - скока хошь, столбцов - 250-1600 в зависимости от типа. Но даже наличие таблицы с 150 полями как бы заставляет задуматься о целесообразности... Но если и это ограничение достигнуто - его легко обойти. Как - напишу ниже, немного в др. контексте.
>>А зачем join-ы? А вдруг в тех двух таблицах внезапно появятся данные... Обычно,
>>если "вдруг" настает и нужно хранить доп. данные, делают ALTER TABLE
>>или создают новую таблицу.
>Нступает "вдруг", вы делаете ALTER TABLE и добываляете еще поле (или несколько).
>Потом еще "вдруг" ... Так может сразу выделить в отдельную таблицу?
>К тому же после каждого ALTER TABLE придется корректировать скрипты.
Да, так делают. Но не сразу. Делить таблицу из 10 полей может быть нецелесообразно. Потому, что при запросах с "where name1 like '...'" тупой sequential scan может выполниться быстрее чем несколько join-ов с таблицами, в которых хранятся отдельные вынесенные св-ва сущности. А еще каждый join потребует seq scan или index scan, ведь у вас же есть условия соединения, да? Да и читабельности коду с такими запросами это не добавляет.
Если "вдруг" наступает внезапно и много раз, и таблица уже сильно разрослась вширь, делают очень просто: из всей сущности выделяют поля, которые редко или никогда не меняются и те, которые меняются часто (это для случая увеличения производительности индексов, дисковой подсистемы, кешей и проч.); либо выделяют поля, которые часто используются в типовых запросах и те, которые редко. И уже эту часть выносят в отдельную таблицу.
Типичный пример: таблица с данными о товарах электромагазина. Имеет смысл вынести все второстепенные хар-ки товара (большое описание, маркетинговая лабуда, цвет, кол-во в упаковке, инфа, которую решили добавить "вдруг", еще одно "вдруг"-поле и т.д.) в отдельную таблицу, а id, наименование и размеры оставить в первой. Ибо в работе на один запрос типа "хочу все знать о товаре" придется сотня запросов типа "положить id-такой-то в basket с quantity=100500", "сколько штук id-такого-то поместится в морской контейнер" и т.д. Конечно, к такому подходу легко прикрутить ваш принцип вынесения полей сущности в отдельные таблицы (юзаем только то, что надо; дырявых таблиц нет), но выигрыша он не даст, хотя бы по той же причине, что seq scan по таблице может быть быстрее нескольких join-ов.
О, мысль пришла: а ведь графическое представление БД по вашему принципу может способствовать инфаркту даже у закаленного спеца. Опасно! :)) Конечно, проектировка БД - это всегда компромисс. Между скоростью и понятностью, надежностью и ресурсами... Можно создать БД, которая работает быстрее любого биллинга сотового оператора при размерах больше, чем все биллинги ОПСОСов в мире. Но разобраться в ней и добавить новую фичу сможет только один человек. И требует за свою работу 100000 евро в час... Это я к тому, что, возможно, ваши методы были актуальны, когда вместо одного hdd на 100Мб можно было сделать ремонт в квартире, а проц 486DX2 был завистью всех ит-шников района. Но сейчас они имеют низкий вес в задаче достижения того пресловутого компромисса. ps: "вашими" методы я назвал не из-за того, что вы их придумали, а оттого, что их пропагандируете.
>>Если вы избавляетесь от лишних полей в основной таблице, зачем
>>поле id в дополнительной? Оно вам там ничего уникально не сыдентифицирует
>>и с ним вы ничего осмысленного не получите. Если в основной
>>таблице вашими методами вы избавились от name1, name2, name3 и таких
>>же description, то напр, запрос вида "обнови второе имя у сущности
>>с id=999" выполнить не получится.
>Избавиться от лишних полей не самоцель. В исходной таблице идут name1, name2,
>name3. Вы точно знаете что их порядок не имеет значение?
А вы точно знаете, что порядок _будет_ иметь значение?
select name1, name2 from... и select name2, name1 from ... - вы об этом?
>Поля id нужны для сортировки. Без них (если нужно) в точном порядке
>вывести значения будет нельзя. А как внести правку? А удалить?
Я вот потому и оставил своей писанины выше, т.к., фактически, спрашивал то же самое. Впрочем, в предложенной модели EAV это сделать можно (если вы знаете точное наименование аттрибута; а если юзаете EAV, то должны знать), а в вашей модели - неизвестно.
Впрочем, я все равно не до конца понял струткуру таблицы из вашего поста с "Если количество полей name и description не соответствуют друг другу то нужно создавать две дополнительные таблицы". Приведите, плиз, пример на sql если, напр., у меня есть name1, name2, name3 и descr1, descr2. А потом и подискутируем )
>А на счет скоращения количества полей, то согласитесь, что довольно существенно поменять
>хотя бы одно поле varchar(999) на одно int.
Тут не соглашусь :) Как можно вот так просто поменять текстовое поле на числовое? Если разработчик БД для хранения, напр., текущего курса валюты использует varchar(999), то я бы его перевел обратно в 5-й класс школы.
А если в общем, то как смена типа поля коррелирует с сокращением количества? :)
>>вообще кошернее смотреться будет: вместо ... JOIN b on (a.id=b.parent_id) вы
>>напишете ... JOIN b using(id). А те субд, что умеют NATURAL
>>JOIN, так вообще сказка: ... NATURAL JOIN b. Согласитесь, удобнее.
>>По большому счету, это мое утверждение спорно, но лишь в том случае,
>>когда на свет вылазят защитники принципа "имя таблицы не должно дублироваться
>>в именах столбцов"
>Соглашусь что утверждение спорно :)
>Дело привычки по большому счету
Не, я согласился с собой, что мое утверждение спорно в том случае, когда на свет вылазят тролли (редкое явление). А в остальных 99% случаев - я сильно "за".
Я бы сказал, это дело ситуации (99%), а не привычки. И опыт это подтверждает. Напр. в данный момент, расширяя функционал некоего сайта, а уже просто запарился делать join-ы с условием типа ON(что_то_id=что_то), когда PK обозван что_то_id, а FK - что_то. Чисто механическая работа утомляет :) В конце концов, человек делает для человека, а не машины. Надо ценить и труд тех, кто придет на смену :) Ну и надо стараться, чтобы ваш код не прослыл индийским. Тем более, что принципы именования - есть некий неформальный стандарт, следование которому облегчает жизнь другим и способствуют укреплению репутации "профессионал" за вами.
>Я не " тотальный рационализатор", но иногда вижу как лучше. И не
>надо кидаться в крайности обзывая меня "фиговый вы "запроектировщик". Фраза "дырявые
>таблицы" придумана не мной и, очевидно, не просто так.
Вы не поверите сколько людей вокруг, которые считают, что "видят лучше". %)) Но не видят перед глазами труд и опыт других. Впрочем, СУБД разрабатывают тоже далеко не дураки. И будь вы таким, мои доводы разбили бы в пух и прах за четыре предложения :) О вас мне сложно судить, могу только предполагать, что если вы - человек с несколькими вышками за плечами, то основываетесь на методах "старой" школы, а если молодой и начинающий спец, то просто все - это дело опыта.
А про "запроектировать" я съязвил скорее в том контексте, что в определенных средах есть уже давно устоявшаяся терминология в общении, а всякие девиации годятся для цитат на башорг. Ну это примерно как спросить у военного на стрельбище "а че за патрончиками вы пуляете" вместо "доложите о типе используемых выстрелОв".
>А! Так это чтобы дух отвести?
>Кошке привет!
Ну и Вам хорошего остатка Вечера Пятницы! ;)
Вариант для распечатки
on 16-Мрт-10, 10:23 
