30.04.2008, 16:08
|
#1
|
Участник
Регистрация: 28.11.2005
Адрес: Москва
|
Цитата:
Сообщение от SHiSHok
Философия обьектной модели это замечательно, но зачастую приходится бороться за производительность системы (особенно с течением времени). Так вот одной из целей проекта я всегда ставлю выбор такого решения, которое в дальнейшем не приведет (минимально отразится) к ухудшению производительности приложения. А вот тут хорошобы цифры реальные иметь для анализа
Ну какие тут могут быть конкретные цифры? Если у вас используется для той же таблицы клиентов штатный режим кэширования - это один расклад, если вы его меняли (скажем, боролись с рассинхронизацией кэшей нескольких АОСов) - это другой расклад, если вы используете тот же Oracle и настроили в рабочей базе, чтобы вся таблица CustTable всегда деражалась в памяти, - это третий расклад...
Понятно, что при работе с СУБД нужно думать о производительности, но если посмотреть на то, что в куче мест стандартного приложения методы дергают записи из таблиц целиком, чтобы взять одно поле, то такие попытки улучшить производительность начинают выглядеть как сизифов труд... Мне кажется, надо все же "плясать от" предметной области, а оптимизацией заниматься уже после - по факту. Потому что если изначально реализовать "неадекватную" структуру данных, то никакие такие мелкие хитрости и оптимизации не спасут. Ну сколько у вас записей в таблице клиентов, сотня, тысяча?.. Посмотрите на тот же номенклатурный справочник, сколько в него полей понапихано, а ведь там бывают десятки тысяч записей - и ничего, работает система как-то...
|
|