GranmerВ принципе, другой реакции и ждать было нечего. Вопрос криво задан :).
Попробую уточнить. Проектируем адресный план.
1 вариант. Таблица - 11 полей: 8 из них являются идентификаторами справночников (страна, область, город улица и т.п.) заканчивается таблица номером помещения и ещё некоторыми параметрами. Т.е. в данном случае справочники не выстраиваются взаимосвязями иерархически (страна - области страны - области), а эти ваимосвязи харанятся все вместе в каждой строчке таблицы. Т.е. первичный ключ квартиры получается составной (проимерно из 8 полей) или можно ввести отдельное уникальное поле.
2 вариант. Справочники соединяются согласно НФ т.е. выстраивается иерархия взаимосвязанных таблиц (страна - области страны - области - города областей - города и т.д.).
Во втором варианте больше количество таблиц - соответственно больше JOINов в первом одна таблица, но существенного размера, в которой частенько для получения информации верхнего уровня придется использовать группировки.
Вот и вопрос, что лучше. Может есть у кого-нибудь доводы какие?Нормализация придумана не для ускорения или замедления выборки (одни запросы она ускоряет, другие замедляет, ну и шо?) Нормализация нужна для устранения избыточности, которая есть потенциальный источник противоречий, то есть потери целостности БД. То есть если у вас в каждую запись заносится
8 значений, которые точно избыточны, то что помешает внести некоррекное сочетание улицы с одного города с другим городом (и т.п.)? Чтобы предотвратить такие ошибки вам нужно очень сильно попотеть: писать триггеры и т.д. Да и не факт, что в итоге организация целостности "ручками" выйдет без ошибок. То есть поймите, вы просто меняете надежность на скорость. Да и на скорость ли? Да и стоит ли оно того?

Сергей08Для меня это решилось когда узнал , что существует ещё
концептуальное проэктирование баз данных. Сергей, это чрезвычайно странная для меня фраза. Дело в том, что наличие такой вещи как концептуальное проектирование БД вообще никак не связано с наличием такой вещи как нормализация. Для меня это прозвучало так же странно, как, скажем, "для меня проблемы со здоровьем решились, когда я узнал о существовании голливудских фильмов". То есть понятия из разных областей, "в огороде бузина, а в Киеве дядька". Вы бы не могли пояснить, что именно вы имелии в виду?
Сергей08В каждом конкретном случае приходится решать на какой НФ
остановится. На 3-й? А может у нас будет не более 100 строк и не стоит даже на 2НФ заходить! Чрезвычайно странные и неверные критерии оценки. Так никто не проектирует. Кто вас учил этакой глупости (чем больше строк, тем выше д.б. нормальная форма)? Это не наезд, просто в жизни я сталкивался с существованием якобы "гуру" которые молодых учат так: "книги фигня, щас я скажу как на самом деле", и при этом забивают им мозги всякой ересью. Ощущение, что вы с кем-то подобным столкнулись, и кто-то вас плохому научил.
Сергей08По моему мнению проэктирование бд это творческий процесс. Почти интимный. Только на месте, поговорив со всеми и оглядевшись можно решить какая должна быть структура бд.Да ни за что. Самые плохие БД выходят, когда к их проектированию подходят как к "творчеству", а не как к строгой инженерной дисциплине.
Среди всех процессов разработки ПО только один является наиболее подкрепленным теорией, предсказуемым, хорошо изученным и описанным. Это проектирование реляционных БД.
Это не значит, что это совсем простой процесс, без головной боли и принятия трудных решений, без творчества и находок. Но преподносить его как "интимное таинство", доступное чуть ли не "посвященным", обычно значит просто не знать полноты теории и не уметь ее применять.
Не обижайтесь, прошу, я не хочу вас обидеть или высмеять, все мы учимся и ошибаемся.

2 Сергей08
Совет: для цитат используйте не [[ src ]], а [[ quot ]].
Сергей08 mir это чрезвычайно странная для меня фраза. Дело в том, что наличие такой вещи как концептуальное проектирование БД вообще никак не связано с наличием такой вещи как нормализация.
Да согласен я с этим. Это один из путей получения нормальной формы. Но это путь не допускающий перенормализации и позволяющий получить нормальные формы. Нормальные формы, которые будут не только нормальными, но и обьекты описываемые таблицами будут отражать обьекты в первую очередь технологического процесса, а затем уже реального мира. Странно. Говорите, что согласны, но следующими словами показываете иное. Еще раз: проектируете ли вы на концептуальном или логическом уровне, это никак не связано с тем, будет ли использована нормализация (да и вообще с качеством полученного проекта). Это всего лишь разные уровни абстракции. Похоже, у вас какое-то сугубо свое понимание концептуального проектирования.
Понятие перенормализация , вообще говоря, не существует, это что-то мутное, формально не определенное. С понятием «реальный мир» у вас тоже непонятно, ибо я всегда считал, что объекты технологического процесса вполне к нему относятся.
Сергей08Здесь я имел ввиду , что нужно очень добросовестно поговорить со всеми пользователями и заказчиками на месте и лично. Определить,например, делать две таблицы автомобиль и водитель или всё таки одна таблица- автомобиль с водителем. И т.д. Некоторые "технологические" обьекты "выплывают" после беседы с самым , что ни на есть рядовым работником. Во многом так, но здесь вы говорите о качестве проведенного анализа предметной области, а не о качестве проектирования. Я эти понятия не путаю, и вам предлагаю не смешивать. Проектирование без качественного анализа обречено, но уж если таковой выполнен, то проектирование РДБ есть процесс относительно строгий и технологичный. Незачем его "мистифицировать".
Сергей08Работал в небольшой фирме. На тот момент там было 40 сотрудников.
Для описания их по 'нормальному' нужно было 3 , а то и 4 таблицы. Я предположил, что если даже кол-во сотрудников вырастет в 100 раз и при этом не будет перехода на другую платформу то решил, что нормализовать ради того, что бы нормализовать по крайней мере глупо.Небольшие задачи и в Excel’е простые люди решают, с помощью одной мега-таблице, и не горюют, всю целостность отслеживают «глазами». Но если со временем объемы данных, количество пользователей или сама задача распухают, то зоркий глаз не помогает, и наступает полная задница. Однако то, что простительно простому пользователю, вряд ли можно простить специалисту. Зачем даже на маленькой задаче делать плохо, если можно сделать хорошо? Тем более, что усилий особых и не надо.
Сергей08 Но, например, проэктирование баз данных для аналитических систем принципиально отличается от проэктирования учётных. Это не так, точнее, не совсем так. Отличия есть, но вовсе не принципиальные. Скажем, РСУБД Sybase IQ обычно вообще не требует специального проектирования DSS.