Проектирование крупных приложений БД

[Yurk@]

Ну а теперь представим, что в результате фильтрации пользователь выбрал лимон записей. И что тогда? Не показывать их ему? Сказать, что ему столько не надо?

1. научить пользователя пользоваться нормально фильтром
2. ну а раз выбрал - показываем (тут в игру уже вступает "частичный фетч") он то и будет доставать данные порциями

кака показывает опыт - с использование фильтра максимум выбирается до нескольких тысяч и все (и то только когда это нужно для статистики), а во всех остальных случаях RecordCount < 20 записей

[Аватар]

Ну а теперь представим, что в результате фильтрации пользователь выбрал лимон записей. И что тогда? Не показывать их ему? Сказать, что ему столько не надо? Вопрос опять же не в том. Вопрос в том, что данные в гриде сидят в памяти. Fetch из DataSet отдает данные порциями. Т.е. мы при DBGriid + DataSet и грамотной настройке не отожрем пару гигабайт памяти. А вот при query + StringGrid - запросто. Вывод же данных на нашей совести.

Сожрем, стоит только выполнить DataSet.Last, то все данные потянутся в DataSet

[MarazmDed]

Сообщение от Yurk@

1. научить пользователя пользоваться нормально фильтром

Не катит. 1) пользователь может быть беспробудно туп (что часто бывает) 2) пользователь может банально ошибиться 3) пользователь может не знать, что по такому фильтру выплюнется мильон записей.

Сообщение от Yurk@

2. ну а раз выбрал - показываем (тут в игру уже вступает "частичный фетч") он то и будет доставать данные порциями

Мысль понятна.

[MarazmDed]

Сообщение от Аватар

Сожрем, стоит только выполнить DataSet.Last, то все данные потянутся в DataSet

И останутся в памяти? Даже те, которые в датасете находятся в начале? Т.е. в Delphi из коробки нет нормального механизма работы с данными?

[Yurk@]

а какой еще нормальный механизм если человек нажал Ctrl+End что = Last = выгрузить абсолютно все записи в память для работы с ними ?
в данном случае все что тут можно сделать - это предупредить пользователя что данных будет ОЧЕНЬ много ивыгружаться они будут ОЧЕНЬ долго. ну и на этом фоне вывести окно с потдверждением или отменой действия

[MarazmDed]

Сообщение от Yurk@

а какой еще нормальный механизм если человек нажал Ctrl+End что = Last = выгрузить абсолютно все записи в память для работы с ними ?
в данном случае все что тут можно сделать - это предупредить пользователя что данных будет ОЧЕНЬ много ивыгружаться они будут ОЧЕНЬ долго. ну и на этом фоне вывести окно с потдверждением или отменой действия

Можно в памяти держать постоянно только 1000 записей например, а предыдущие - грохать. Ну к примеру. Вариантов много можно придумать. Вопрос - какой вариант реализован в DataSet дельфей.

[Аватар]

MarazmDed, как бы вы не крутили, а километров кода для серьёзного большого проекта не избежать, в том числе и для организации рутинных вещей. Нет в том же дельфи приспособ для удовлетворения всех потребностей программиста для организации вычислительного процесса. Если это не устраивает, то браться за серьёзный проект не стоит. Как-то уменьшить можно используя процедуры и функции вместо повторяющихся похожих по логике кусков кода. Для части компонент можно написать своих наследников, в коде которых закладывать то, чего вам не хватает в стандарте. Что касается доступа к данным базы, то не пользоваться Table и аналогичными компонентами. Только Query. Для пресечения тяжеловесных передач данных с сервера хорошее средство есть в MYSQL: LIMIT - выбор заданного числа записей начиная с. Аналог в Firebird - FIRST ... SKIP. В MSSQL хуже, есть только TOP, приходится извращаться, хорошо хоть начиная с 2005-го появился ROW_NUMBER. В любом случае использование этих средств - дополнительная нагрузка на изнеженного программиста - куча дополнительного кода

[MarazmDed]

Сообщение от Аватар

MarazmDed, как бы вы не крутили, а километров кода для серьёзного большого проекта не избежать, в том числе и для организации рутинных вещей. Нет в том же дельфи приспособ для удовлетворения всех потребностей программиста для организации вычислительного процесса. Если это не устраивает, то браться за серьёзный проект не стоит. Как-то уменьшить можно используя процедуры и функции вместо повторяющихся похожих по логике кусков кода. Для части компонент можно написать своих наследников, в коде которых закладывать то, чего вам не хватает в стандарте. Что касается доступа к данным базы, то не пользоваться Table и аналогичными компонентами. Только Query. Для пресечения тяжеловесных передач данных с сервера хорошее средство есть в MYSQL: LIMIT - выбор заданного числа записей начиная с. Аналог в Firebird - FIRST ... SKIP. В MSSQL хуже, есть только TOP, приходится извращаться, хорошо хоть начиная с 2005-го появился ROW_NUMBER. В любом случае использование этих средств - дополнительная нагрузка на изнеженного программиста - куча дополнительного кода

Я понимаю, что километров кода не избежать. На то и программист. Вопрос в том, что есть инструменты в Delphi, которые для крупных проектов не годятся. Зачем они были созданы? Для студентов? Или я чего-то не знаю? Один приличный ответ на данную тему я нашел здесь: http://pyatochkin.blogspot.ru/2010/1...c-pattern.html
Пожалуй, именно этот подход и применю для текущего проекта.

[Yurk@]

есть инструменты в Delphi, которые для крупных проектов не годятся

это абсолютно не так ... любой крпный проект состоит из кучи маленьких деталейи простеньких компонентов которые все вместе и образую огромную мощь системы.
все дело лишь в том - как правильно использовать это все

[MarazmDed]

Сообщение от Yurk@

это абсолютно не так ... любой крпный проект состоит из кучи маленьких деталейи простеньких компонентов которые все вместе и образую огромную мощь системы.
все дело лишь в том - как правильно использовать это все

Дык про то, как правильно использовать компоненты для работы с БД я и спрашиваю Мне видится абсолютно нездоровой ситуация, когда я должен многократно делать одну и туже работу.