Developing.ru

Согласен целиком и полностью - самому такое решение не сильно нравится - но погоняли и так и так разницы особой не заметно в производительности, но если хочется заказчику - то куда деваться и мне проще и с ним конфликта нет :)

[b]Kolinus[/b], ну тогды уболтал. Но на то и правила, чтобы были исключения :)
Третьей нормальной формы тоже не всегда придерживаться надо. А вот когда от подобных правил отступаешь, всегда раз 10 подумаешь - не накосячил ли где.

2 в 1 - и то и другое в одном лице.

[quote]Но заказчик - не хочет закладок. [/quote]
А заказчик тот самый Admin, который этой приблудой пользуется или же начальник, который эту форму раз в год созерцает? :)

Это понятно.
Но заказчик - не хочет закладок.
Хочу все !!
Так что ...можно конечно скрывать - я писал выше но надо ли ???
Ведь скорость работы реально не возрастет
Памяти много не сожрет - нам-то сервер приложений интерфейсы отдаст а нужные данные подкачать из базы через интерфейсы по мере отображения - чем не вариант?

Admin тоже пользователь :) А признаков завсегда добавить можно. Либо по диапазонам для numeric полей и дат, либо по алфавиту для (var)char. В крайнем случае разложить по 10 закладкам "первые 50", "вторые 50" и т.д.
Так что [b]все[/b] данные отдают либо те, кто ленится думать, либо те, кто ленится делать :) . НЛ.

Согласен целиком и полностью.
Но у меня указано слово ИНОГДА - в этом-то и есть ключ.
Я согласен чт окак правило пользователя интересует только ма-а-а-аленькая часть данных.
Но например:
есть локальная сеть.
есть база данных априорно на одном сервере.
есть сервер приложений априорно на другом.
есть морда для работы с данной базой обладающая определенным функционалом.
есть пользователь - администратор всей этой базы.
база большая 10-30 тысяч наименований.

пользователь хочет посмотреть все наименования по одному признаку.
априорно это около 1000 наименований.
если каждый раз по 100 наименований отдавать - можно. но тогда надо где-то хранить кучу всего для захвата нужной пачки данных, плюс надо учитывать что пользовательможет потянуть за скролл - то есть не предсказуемо какая следующая пачка понадобиться.
Здесь по-моему логичнее отдать пользователю ВСЕ данные по запросу

[b]Kolinus[/b], ну дафай пофлеймим :)

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

В-третьих, когда ты вытягиваешь длинный список из БД, то либо данные могут за время вытягивания оказатся неактуальными, если у тебя идёт dirty reading, либо все операции записи/обновления блокируются, до тех пор, пока ты не прочитаешь все записи.
Тоже не есть карашо, особливо если речь идёт о веб-сервере с высокой активностью.

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