Стратегия организации обмена между браузером и сервером

Добрый день!

Только начинаю заниматься PHP, в целях обучения и возможного будущего портфолио, делаю свой первый проект на голом PHP без существующих фреймворков, со стандартным взаимодействием: данные из базы данных посылаются в браузер, пользователь работает с таблицами, отредактированные данные через AJAX возвращаются серверу, где благополучно записываются в таблицу.

Основной вопрос: какова стратегия обмена объемом информации в случаях:

Пример 1:

Таблица в 10000 строк. Послать ее всю браузеру, держать в оперативке, и выводить пользователю в DOM порциями по 100 строк или послать только 100 строк, а далее по запросу или по скроллингу подкачивать данные На клиент? В первом случае мы уменьшаем количество обращений к серверу, во втором случае не загружаем клиентский компьютер.

Исходя из каких параметров делать выбор? Есть ли какие-то стандарты или вопрос вкуса и целевой аудитории: то есть рассчитан ли сайт на работу с любого маломощного девайса или используется только в корпорации с нормальным железом?

Пример 2:

При клике на таблицу должна показаться форма для расширенного редактирования данных строки. Опять же вопрос: подгрузить ли ее сразу и держать HIDDEN, либо подгружать только при клике. Здесь вопрос наверное не столько в объеме оперативки, сколько в размере DOMа.

Исходя из чего обычно принимают решения в подобных случаях? Заранее спасибо за аргументированные мнения.

0

Сообщение от renat_dmitriev Таблица в 10000 строк

Вы хоть представляете, сколько оперативки съест хром?) Лучше ajax'ом посылать только то, что пользователю сейчас нужно.
Форму лучше загрузить сразу, лишней не будет, но зато при первом клике не будет тормозить

0

сам чистый РНР не выводит "порциями".
и кстати, 10000 строк в таблице - это чтоб юзера тупо убить на месте? он на первой тысяче сдуется

0

Сообщение от renat_dmitriev Пример 1

Не нужно грузить большие количество строк к пользователю. Лучше постраничная навигация/подгрузка при прокрутке.

Сообщение от renat_dmitriev Пример 2

Если данных в форме много и все они однотипные -- можно сделать одну скрытую форму и с помощью JS подставлять в неё редактируемые данные. Нет смысла для каждой строки свою форму делать.
Либо подгружать при клике, если данные под одну форму не подгонишь.

Сообщение от renat_dmitriev Исходя из чего обычно принимают решения в подобных случаях?

Исходя из здравого смысла. Нет смысла, как в первом примере, грузить в браузер 10000 строк. Разве только если это отчёт какой-то.

0

Сообщение от DevAlone Вы хоть представляете, сколько оперативки съест хром?

Давайте подсчитаем: 10000 строк, 10 колонок, допустим по 16 байт в среднем каждое значение. Итого: 1,6 мб оперативки. По моему это вообще ничто.

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

Сообщение от Para bellum Не нужно грузить большие количество строк к пользователю. Лучше постраничная навигация/подгрузка при прокрутке.

В интерфейсе само собой. Вопрос о том, откуда подгружать? Держать данные в массиве js и по запросу подгружать из него, не обращаясь к серверу, или же каждый раз подгружать с сервера?

Добавлено через 3 минуты
Вобщем то, что при каждом клике пользователя скрипт будет запрашивать сервер - проблемы вызывать не должно, верно? При большом количестве пользователей на больших сайтах программисты стараются уменьшить количество обращений к серверу или никто об этом не парится и вопросы решаются более подходящими серверами?

0

Сообщение от renat_dmitriev Исходя из каких параметров делать выбор?

Из ТЗ. Показывать всю таблицу сразу или частично - этот вопрос решается с заказчиком.

В целом частичный показ, конечно, выгодней по ресурсам.

Сообщение от renat_dmitriev При клике на таблицу должна показаться форма для расширенного редактирования данных строки. Опять же вопрос: подгрузить ли ее сразу и держать HIDDEN, либо подгружать только при клике. Здесь вопрос наверное не столько в объеме оперативки, сколько в размере DOMа.

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

Сообщение от renat_dmitriev Давайте подсчитаем: 10000 строк, 10 колонок, допустим по 16 байт в среднем каждое значение. Итого: 1,6 мб оперативки. По моему это вообще ничто.

Там речь про хром (браузер), а не сервер. Если не ошибаюсь, отрисовка таблиц для браузера - достаточно ресурсоёмкая задача, особенно если таблица большая. И особенно если компьютер слабый.

Сообщение от renat_dmitriev Вопрос о том, откуда подгружать? Держать данные в массиве js и по запросу подгружать из него, не обращаясь к серверу, или же каждый раз подгружать с сервера?

Лучше через AJAX.

0

Сообщение от renat_dmitriev В интерфейсе само собой.

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

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

Сообщение от renat_dmitriev на больших сайтах программисты стараются уменьшить количество обращений к серверу или никто об этом не парится и вопросы решаются более подходящими серверами?

И то, и другое. Оптимизацию никто не отменял. Чем меньше запросов -- тем лучше. Но в пределах разумного.

0

Сообщение от renat_dmitriev Давайте подсчитаем: 10000 строк, 10 колонок, допустим по 16 байт в среднем каждое значение. Итого: 1,6 мб оперативки. По моему это вообще ничто.

Будем считать средний размер страницы 5M. 1.6M это 30% от средней страницы. Большую часть этих данных пользователь не увидит. Плюс 16 байт на колонку как-то подозрительно мало. Также помимо количества обращений к серверу нужно помнить, что вытащить из базы 100 строк легче чем 10 000.

0

Сообщение от Para bellum Тут нужно задать себе вопрос: а нужны ли клиенту все эти данные?

А мы заранее не знаем и даже пользователь заранее не знает. Ну например база счетов. он смотрит на нее задумчиво и думает: дай-ка я отсортирую счета по этому заказачику или по такому-то периоду. И возникает вопрос, если условные 10000 записей занимают 1,6 мб оперативки, то стоит ли обращаться к серверу?

Сообщение от Para bellum И то, и другое. Оптимизацию никто не отменял. Чем меньше запросов -- тем лучше. Но в пределах разумного.

Я понял! попробую сделать это параметризировано, и чтобы этот параметр можно было менять.

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

Сообщение от Jewbacabra Также помимо количества обращений к серверу нужно помнить, что вытащить из базы 100 строк легче чем 10 000.

В каком смысле легче? Быстрее или что? Если 10000 записей получаются и передаются с сервера на клиент меньше чем за секунду, если мы очистили за собой память и потом до конца работы пользователя с таблицей обращений к базе больше не происходит - то проблемы вроде как нет? Но в остальном вы наверное правы.

0

Сообщение от renat_dmitriev А мы заранее не знаем и даже пользователь заранее не знает.

Вот отсюда и надо плясать. Значит все данные грузить к нему не нужно.

Сообщение от renat_dmitriev думает: дай-ка я отсортирую счета по этому заказачику или по такому-то периоду

В таком случае лучше не отдавать всё в браузер. Всё можно отдать, если уверены, что они ему точно понадобятся.

0

Сообщение от Para bellum В таком случае лучше не отдавать всё в браузер. Всё можно отдать, если уверены, что они ему точно понадобятся.

Да, наверное вы правы. Спасибо!

0