Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2008.02.03;
Скачать: CL | DM;

Вниз

К вопросу о культурном проектировании реляционных БД   Найти похожие ветки 

 
Kostafey ©   (2007-12-24 14:25) [40]

> [35] Бакук ©   (24.12.07 05:11)


> А приведите пример, чтобы необходимо было использовать такой
> подход?

[20] Sergey Masloff   (22.12.07 17:17)
очень хороший пример привел.

Со всем остальным согласен на 100%


> [37] Anatoly Podgoretsky ©   (24.12.07 11:14)
> > Раньше я так и делал.
> Еще одна жертва венгерской нотации и работа с Паскалем не
> помогла.

Каюсь, ибо я грешен, :)
теперь делаю по-другому
см. [33] Kostafey © :
> Но когда таблиц много, я думаю лучше пользоваться
> полным именем поля, т.е.:
>
> Gruppa:
> id
> name
> Student:
> id
> FIO
> Gruppa_id //В какой группе студент
>
> Select *
> Form Student, Gruppa
> Where Student.Gruppa_id=Gruppa.id


 
MOA ©   (2007-12-24 23:48) [41]

Моё СМ - любое нарушение нормализации приводит в итоге - не, не сразу, конечно - лет так через 3 - к огромной величины гемморою.
Сам был грешен, тоже думал "зато работать будет быстрее". Нет. Не быстрее. Селективность индексов по "классовым" полям как правило, никакая, оптимизатор скорее предпочтёт перебор (утрирую) чем такой "индекс", но геморрой с будущими запросами - ужасный. Самое печальное - что быстрее-то не получается, через 2-3 года тот кажущийся "прирост производительности" будет уже ничтожен  - а то и отрицательный.


 
Kostafey ©   (2007-12-26 00:59) [42]

> [41] MOA ©   (24.12.07 23:48)

Спасибо, очень полезная информация.


 
Sergey13 ©   (2007-12-26 10:10) [43]

> [41] MOA ©   (24.12.07 23:48)

Это лечится правильным тестированием системы. Можно нагенерировать данных на 5-10 лет и смотреть производительность на "реальных" объемах. Полностью нормализованные базы могут тормозить не менее (а то и более) денормализованных. Другое дело, что денормализация обычно делается за счет избыточности информации, а это в свою очередь порождает проблему ее целостности, за которой надо следить.

ИМХО истина всегда где-то посередине.

К тому же борьба за производительность не заканчивается с написанием системы. Это постоянная работа на все время жизни продукта.



Страницы: 1 2 вся ветка

Текущий архив: 2008.02.03;
Скачать: CL | DM;

Наверх




Память: 0.54 MB
Время: 0.025 c
2-1199617113
deadteachers
2008-01-06 13:58
2008.02.03
Ускорить процесс загрузки?


15-1198493736
FreeBSD
2007-12-24 13:55
2008.02.03
Gambas


2-1199868237
DevilDevil
2008-01-09 11:43
2008.02.03
Почему может возникать неправильная максимизация ?


15-1198422204
Sergey Masloff
2007-12-23 18:03
2008.02.03
А почему просто не удалять мусорные ветки?


15-1198741568
Cj
2007-12-27 10:46
2008.02.03
Уязвимость Каспера 6.0.2.614