Я читал статью Вьетнамская компьютерная наука Теда Ньюарда. Хотя я многого не понимаю или до конца не понял, при чтении этого параграфа меня поразила мысль.
Проблема частичного объекта и парадокс времени загрузки
Давно известно, что обход сети, например, выполняемый при создании традиционного SQLзапрос, занимает значительное количество времени для обработки. ... Эта стоимость явно нетривиальна, поэтому в результате разработчики ищут способы минимизировать эту стоимость, оптимизируя количество обращений и полученных данных.
В SQL эта оптимизация достигается путем тщательногоструктурирование запроса SQL, обеспечивающего получение только нужных столбцов и / или таблиц, а не целых таблиц или наборов таблиц. Например, при построении традиционного пользовательского интерфейса детализации разработчик представляет сводное отображение всех записей, из которых пользователь может выбрать одну, и после выбора разработчик затем отображает полный набор данных для этой конкретной записи. Учитывая, что мы хотим выполнить детализацию реляционного типа Persons, описанного ранее, например, два запроса для этого будут иметь следующий порядок (при условии, что выбран первый):
SELECT id, first_name, last_name FROM person;
SELECT * FROM person WHERE id = 1;
В частности, обратите внимание, что извлекаются только те данные, которые требуются на каждом этапе процесса, - в первом запросе необходимая сводная информация и идентификатор (для последующего запроса, если имя и фамилия не будут ')достаточно идентифицировать человека непосредственно), а во-вторых, оставшиеся данные для отображения. ... Это представление о возможности возврата части таблицы (хотя все еще в реляционной форме, которая важна по причинам закрытия, описанным выше) является основополагающим для способности оптимизировать эти запросы таким образом - большинство запросов вФактически, требуется только часть полного отношения.
Скелетные экраны
Скелетные экраны - это относительно новая концепция дизайна пользовательского интерфейса, представленная в 2013 году Люком Вроблески вэтот документ . Он рекомендует избегать указателей загрузки, чтобы указывать загрузку, и вместо этого постепенно строить элементы пользовательского интерфейса во время загрузки, что создает у пользователя ощущение, что все быстро прогрессирует и прогресс достигается, даже если он на самом деле медленнее, чем при использовании традиционногоиндикатор загрузки.
Вот скелетный экран, используемый в приложении чата Microsoft Teams. Это отображается во время ожидания поступления сохраненных журналов чата из базы данных.
Использование загрузки данных стиля экрана скелета в качестве парадигмы для извлечения данных
В то время как статья Ньюарда фокусируется на объектно-реляционных сопоставителях, я думал о структурировании извлечения данных.
Приведенный выше абзац указывает на проблему с запросом слишком большого количества данных за один раз, увеличивая время поиска данных, пока все указанные данные не будут собраны. Что, если, как в примере с SQL в Neward выше, меньшие порции данных были извлечены по мере необходимости и загружены по частям в приложение?
Я думаю, это потребует фундаментального сдвига в логике запросов к базе данных. Очевидно, это было бы нелепым предложением реализовать это в коде приложения. Если бы ваш ежедневный разработчик написал многоуровневую схему поиска для извлечения одного объекта, это было бы безумием. Скорее, потребуется какой-то встроенный метод, с помощью которого разработчик может указать, какие свойства считаются необходимыми (имя пользователя, идентификатор, разрешения, роли и т. Д.), Которые должны быть извлеченыполностью, прежде чем двигаться вперед, и какие свойства являются вспомогательными. В конце концов, многие пользователи приложения перемещаются по приложению быстрее, чем могут заполнить все данные, если они знакомы с приложением и им просто нужно перейти на определенную страницу. Все, что им нужно, - это достаточно данных для загрузки, что является целью этой схемы.
На стороне базы данных, скорее всего, будет ряд небольших поисков, а не большой. Я знаю, что это, вероятно, дороже, хотя я не уверен в технических деталях, и хотя производительность базы данных может пострадать, производительность приложений может улучшиться, по крайней мере, так, как это воспринимает пользователь.
Заключение
Представьте, что вы загружаете свой Instagram и загружаете первую серию фотографий (которые вы видите), в два раза быстрее, чем раньше. Фотографии, вероятно, ваш первый приоритет. Не имеет значения, если для заполнения имени пользователя, индикатора уведомлений и изображения профиля потребуется несколько дополнительных секунд, поскольку вы уже получили ожидаемые данные и начали использовать их как пользователя. Сравните это с загрузкой структурных данных. Никто не заботится о загрузке их имени пользователя или логотипа компании. Они хотят видеть контент.
Я не знаю, является ли это ужасной идеей или тем, что уже рассматривалось, но я хотел бы получить отзыв об этом.
Чтоты думаешь?
Возможно ли это с технической точки зрения?