Главная страница
    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.52 MB
Время: 0.087 c
2-1198248676
botaniQ
2007-12-21 17:51
2008.02.03
Ошибка "has encountered a problem and needs to close..."


4-1182855752
=BuckLr=
2007-06-26 15:02
2008.02.03
Забрать richtext из ricnedit


15-1198588345
icome
2007-12-25 16:12
2008.02.03
Три задачи на зачёт - Сделай праздник мне на Новый год!


8-1172939370
tio
2007-03-03 19:29
2008.02.03
Насыщенность цветов в CMYK


2-1199874260
Ega23
2008-01-09 13:24
2008.02.03
Версия MSOffice





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский