Как определить, что запись последняя?

Есть прилада с исходником (моя) и БД под аксесом, связь по ADO. В приладе есть много циклов перебора записей. Я перед циклом определяю, сколько в таблице всего строк, удовлетворяющих текущему фильтру, и юзю циклы со счётчиками. А как можно ещё? Можно ли в цикле while, не используя счётчик записей в какой бы то нибыло его форме, определить, является ли текущая запись последней? Как именно?

0

Сообщение от oxotnik Не надо подменять понятия. Я говорил о том что,

Где в Ваших постах хоть одно слово о представлении данных?
Только категорические утверждения о том, что перебор результатов запроса в цикле - ламерство..

Ну да ладно, будем считать, что это я плохо смотрел, неправильно понял.. Прошу прощения.

Сообщение от oxotnik Для больших СУБД выгодней делать много мелких запросов, нежели один большой (на скорости клиента это отрицательно скажется, но на системе в целом - положительно).

А вот за это не могу не уцепиться. В примере сказано четко - 1000 записей. Для сервера большой СУБД выбрать что одну запись, что 1000 - примерно фиолетово. Большие запросы начинаются с величин, на пару порядков больше. Поэтому не вижу ни малейшего смысла строить тысячу запросов вместо одного.

0

Сообщение от Black Fregat Где в Ваших постах хоть одно слово о представлении данных? Только категорические утверждения о том, что перебор результатов запроса в цикле - ламерство..

самое начало "спора":

Сообщение от oxotnik то перебор записей на клиенте это самое распоследнее дело (особенно для отображения в виде таблицы).

Сообщение от Black Fregat А вот за это не могу не уцепиться. В примере сказано четко - 1000 записей. Для сервера большой СУБД выбрать что одну запись, что 1000 - примерно фиолетово. Большие запросы начинаются с величин, на пару порядков больше. Поэтому не вижу ни малейшего смысла строить тысячу запросов вместо одного.

Пример абсолютно не показательный. При таком количестве данных что с циклом, что с отдельными запросами разница во времени выполнения будет доли сек. (в пользу большой выборки). Но, если привыкнуть так делать (пихать циклы, туда где можно обойтись запросом), то можно в конечном итоге наткнуться на грабли производительности системы в целом.

0

Сообщение от oxotnik самое начало "спора": перебор записей на клиенте это самое распоследнее дело (особенно для отображения в виде таблицы)

Опять 25.. Сформулируйте, пожалуйста, четко: Вы в принципе признаете, что запросы, возвращающие много строк, могут быть уместны и даже необходимы? Собственно, за всеми вашими словами читается, что это вообще вредная фича. То есть, про обработку таблиц я и не пытаюсь спорить. Но зачем же делать такие грандиозные обобщения?

Сообщение от oxotnik Но, если привыкнуть так делать (пихать циклы, туда где можно обойтись запросом), то можно в конечном итоге наткнуться на грабли производительности системы в целом.

Часто Вы наступали на грабли производительности системы из-за объединения запросов в цикл?

Ладно, я смотрю, беседа становится неконструктивной.

0

Сообщение от Black Fregat Вы в принципе признаете, что запросы, возвращающие много строк, могут быть уместны и даже необходимы?

Признаю. Более того, странно было бы если на каждую строку делался бы отдельный запрос.

Сообщение от Black Fregat Собственно, за всеми вашими словами читается, что это вообще вредная фича.

Еще раз повторюсь (опять 25...). Делать обработку данных в цикле, только для того что бы отобразить эти данные в таблице - моветон. Для примера что я считаю моветоном: Есть куча запросов (или один большой) построенный таким образом что стандартный TDBGrid не может его отобразить, так как хочется. В результате отказываемся от TDBGrid в пользу TStringGrid, и начинаем бегать по результатам запроса(ов), заполняя сетку, так как нам хочется.

Сообщение от Black Fregat Но зачем же делать такие грандиозные обобщения?

Все обобщения сводятся к отображению данных в табличном виде.

Сообщение от Black Fregat Часто Вы наступали на грабли производительности системы из-за объединения запросов в цикл?

Было пару раз, делал систему раскроя материалов на основе циклов, потом ТЗ поменялось и раскрой пришлось ждать пару часов, тогда как SQL-ем это делалось за пару сек.

1

Спасибо, с такими формулировками полностью согласен.

0

Сообщение от oxotnik уж если их сумели отобрать, то и операции над ними не проблема сделать.

Одно из другого не следует. Может я из БД читаю план полного факторного вычислительного эксперимента на модели свободно-вынужденной тепломагнитной гидродинамики? На сиквэле она нереализуема при том, что это обработка. Ладно бы пиэлсиквэл, он хоть процедурный, но хорошую модель свободно-вынужденной и на процедурном языке (любом) несколько лет будешь делать, если вообще сделаешь.

0

Сообщение от taras atavin план полного факторного вычислительного эксперимента на модели свободно-вынужденной тепломагнитной гидродинамики?

понял только слово "план"...

0

Сообщение от oxotnik для представления данных в виде таблицы

Какой именно? Таблица аксеса имеет поля: День недели, номер пары, возможность планирования на данное время. Нука напиш8и запрос, который время пары расставит в заголовках столбцов!

Добавлено через 1 минуту

Сообщение от oxotnik понял только слово "план"...

, а критикуешь мои знания.

Добавлено через 2 минуты

Сообщение от oxotnik если на каждую строку делался бы отдельный запрос

. У меня такой интерфейс связанных таблиц, что иногда и это востребовано, но по таким выборка си сами не ходят, всё свалено на компоненты.

0

Сообщение от taras atavin Какой именно? Таблица аксеса имеет поля: День недели, номер пары, возможность планирования на данное время. Нука напиш8и запрос, который время пары расставит в заголовках столбцов!

а) Я не знаю задачу в целом, поэтому:
б) Я не исключаю что архитектура БД не до конца продумана
г) на "слабо" не ведусь, и "ну ка напиши" - за отдельную плату.

Сообщение от taras atavin , а критикуешь мои знания.

если бы я критиковал твои знания в области ядерной физики или литературы 19 века, то замечание было бы уместно, а так, тут форум программистов, и знания по программированию критикуются, тем более что это не критика, а так "заметки на полях"

Сообщение от taras atavin У меня такой интерфейс связанных таблиц, что иногда и это востребовано, но по таким выборка си сами не ходят, всё свалено на компоненты.

архитектуру БД посмотри внимательно, может и найдешь способ уйти от циклов.

ЗЫ: я вовсе не призываю отказаться от циклов как от атавизма программирования, все что было мной выражено на 3-х станицах этой темы это личное ИМХО (попытался привести доводы в виде скорости работы софта и его модификации/расширяемости). Если с циклами работает и это устраивает, то пусть работает.

0

Сообщение от oxotnik если бы я критиковал твои знания в области ядерной физики или литературы 19 века, то замечание было бы уместно, а так, тут форум программистов

Вот именно. А ты обладаешь такими малыми знаниями, что даже не способен понять класс задач, для которых сиквел не тянет обработку, но берёшься критиковать мои знания самого сиквэла только на том основании, что я юзю циклы после сиквэла. Я бы ещё понял, если бы основанием для критики был запрос на сиквэле, по которому сразу видно, что обрабатываться он будет в десятеро дольше, чем если его переписать. Или если бы ты конкретную задачу не только понял, но и за 5 минут решил на одном сиквэле, а я бы спросил, как оптимизировать решение на сях. А так, критиковать надо тебя. Кстати, при выборе язка для решения каждой задачи следует учитывать не только время исполнения, но и время разработки и объём кода. Представь себе ещё боле дикую ситуацию, в возможности которой я, кстати, сам очень сомневаюсь, но всё же: на сях прога пишется за месяц, исполняется за час, а на сиквэле исполняться будет терцию, но писаться тысячу лет. Тогда выбор сиквэла говорит о не знании сей и нежелании их изучать. По моей задаче соотношение времени разработки скромнее, но в пользу сей. И это только по обработке. А по переофомлению таблицы из реляционной в ортоганальную? Даже если ты это на сиквэле сделаешь, такое решение будет полным извратом не зависимо ни от времени разработки, ни от времени исполнения, а по той лишь причине, что сиквэл для этого не предназначен. И платить за такую глупость я не намерен. Таблица самого расписания, кстати, вообще должна выводится с объединением ячеек, для чего ни один поддерживающий сиквэл компонент не годен, а если нет возможности юзить готовые компоненты, поддерживающие сиквэл, то придётся при отображении перебирать записи. Друго пути нет.

0

oxotnik, taras atavin, давайте знания и прочие достоинства друг друга вы будете выяснять не в теме...

0

Lord_Voodoo,согласен, договоримся на то что у него толще, а у меня длиннее

0

Зелей базу

0