Это проблема PlantUML, нет хорошей документации. Самое полное руководство на сайте (сделано в tex'е) не содержит много важных моментов. Поэтому на разных сайтах подбираешь по чуть-чуть информации. Здесь действительно много хороших примеров.
Мне кажется, эта подобного рода дискуссия не относится к данной статье. Статья все-таки посвящена довольно мелкой теме, как удобно рисовать диаграммы (если они нужны).
Требование Model Visually есть в RUP. Требование итеративной разработки (против которой, насколько я понимаю, направлена Ваша аналогия с движком автомобиля) есть вообще много где. Программисты замечательных продуктов (того же junit5) используют диаграммы в документации.
Ставить все эти очень распространенные паттерны под вопрос можно и полезно, но в рамках значительно более широкого и серьезного обсуждения.
Действительно, включение PlantUML-диаграмм в текст asciidoc — это удобно. Тут больше говорят мои издательские привычки держать спецификации картинок отдельно от документа.
Интересно, тот же RUP говорит: при желании описывайте процесс текстом. И мы этим часто пользуемся. Но в сложных случаях очень часто именно диаграммы позволяют пояснять особенности проектируемой системы стейкхолдерам от пользователей. Об этом также говорится в RUP и это подтверждает опыт.
Опасную иллюзию понимания работы системы может дать и текст и прототипы интерфейсов. Многие пользователи могут вообще не понимать, как будет работать система до того, как ее запустят. На самом деле даже через много лет, после того, как ее запустят.
Диаграммы деятельности, мне кажется, надо стараться делать попроще, избегая больших ветвлений, и, в любом случае, подписи на этой диаграмме не совсем ей соответствуют. Но разные есть случаи, предположим надо так
Мой подход был бы следующем
skinparam defaultTextAlignment center
start
if (condition one) then (no)
if (condition two) then (yes)
if (condition three) then (filled)
:choice two;
(A)
detach
else (blank)
endif
else (no)
endif
else (yes )
endif
label l1
:choice one;
(B)
detach
if () then
(A)
else ()
(B)
endif
stop
Вместо detach можно сразу поставить stop. Именно в этом примере нижний аппендицит, конечно, не нужен. Но в общем случае можно действовать именно так.
Опять же, в данном конкретном случае можно нарушить все нотации и сделать вот так:
Добавлю к комментарию habradante. Картинки PlantUML можно также объединять при помощи Asciidoctor, тогда у Вас будет прекрасная, хорошо читаемая документация без ежей, которую можно представить и в html, и в pdf.
Я рассматриваю PlantUML в первую очередь как инструмент бизнес-аналитика. Уверен, что этот инструмент не получится нормально использовать для проектирования классов или структуры базы данных, для этого есть другие прекрасные продукты. Но его очень удобно использовать для генерации программной документации.
Например, для визуального проектирования структуры базы данных мы используем инструмент DbSchema (который, собственно, и дает на выходе описание структуры в 2bass). Однако помещать ER-диаграммы в документацию — та еще головная боль. Поэтому для генерации документации мы используем именно PlantUML (фактически, создается несколько диаграмм, каждая на подмножество таблиц базы данных). При проектировании структуры базы данных я даже не задумываюсь о том, как визуально она разложится в диаграмме в документации, я всегда уверен, что это будет красиво и заказчик будет доволен.
Другой вопрос, что при проектировании логической структуры данных для понимания и согласования с заказчиком общих требований к системе я обычно использую именно PlantUML. Т.е. сначала структура сущностей рождается в диаграмме классов PlantUML, далее на основе нее разрабатывается структура базы данных в DbSchema, этот же инструмент используется для поддержания структуры в актуальном состоянии, далее документация по этой структуре генерируется автоматически опять же при помощи PlantUML.
Касательно комментария DmitriyDev. Да, все верно, PlantUML позволяет указывать желаемое направление стрелки (например, -r- или -right-), на самом деле, еще и увеличивать ее длину (например --- будет длиннее, чем --). Но, как я писал в статье, у меня не получилось использовать эту функциональность удобно. Пусть уж PlantUML распределяет элементы, как хочет. Я стараюсь влиять на расположение элементов через их группировку, иногда через порядок их указания в спецификации.
Конечно, движок БД работает именно так, как Вы пишите, и получает агрегаты максимально быстро с учетом всех индексов и его понимания требуемого порядка выполнения операций над данными. Но получение агрегатов — это в любом случае затратная операция. Как ни крути, цифры (пусть даже только те, что нужно и без лишних отягощений) надо считать и сложить.
Нехитрое в гриде без полосы прокрутки или с полосой прокрутки, максимум которой соответствует последней подгруженной записи. В статье же речь шла о том, как обеспечить полосу прокрутки, которая позволяет быстро перемещаться по всей таблице. Показано, что это можно сделать с минимальным штрафом на производительность сервера даже при работе с выборками, содержащими миллионы записей. Показано, что offset при этом лучше не применять.
Как работает гугл при отображении картинок можно примерно догадаться, подергав интерфейс. При загрузке страницы данных (для поиска картинок их всего две, вторую можно открыть, промотав до конца первую) из базы данных начинается последовательное вытягивание ссылок на картинки, которые попадают в экранную область. Далее подгружаются сами картинки. На этом гугл пока останавливает работу с сервером. Если далее промотать сразу до конца страницы, то последовательно догружаются остальные ссылки на картинки. Именно последовательно, без перепрыгиваний (иначе быть не может: так работают СУБД — в данном случае очень специфическая но все же СУБД — почему так, поясняется в начале статьи). Это хорошо видно, т.к. гугл, в при резком переходе виснет на несколько секунд. И, даже если потом быстро промотать страницу наверх, мы увидим что все серые квадраты под картинки отображаются мгновенно и соответствуют размерам еще незагруженных картинок. При этом, хотя ссылки все уже подгружены, сами картинки загружаются только те, что попадают в экранную область (с зазором). Это уже к работе с базой данных не имеет отношения, а делается для экономии канала передачи данных.
Возможно, там еще какие-то хитрости применены, но, думаю, примерно алгоритм описан верно.
Дискуссия об 1С — очень интересный результат статьи. Я абсолютно не учитывал, что от бегунка можно вообще отказаться.
Поэтому вопрос хочется исследовать до конца. Укажите, пожалуйста, о какой версии платформы 1С идет речь. Мы только что выяснили, что по крайней мере в 1С версии 8.2 (web-клиент) и в некоторых последующих версиях полоса прокрутки вообще не используется. Это и объясняет высокую скорость работы. И подтормаживания здесь быть не должно ни на 130 миллионах записей, ни на 130 миллиардах. Если база данных держит такую таблицу (это уже больше аппаратный вопрос), значит и считывание записей по ключевым полям не может тормозить. Возможно, в разных версиях 1С реализован разный алгоритм работы с СУБД.
А курсор сам по себе к производительности добавить ничего не может. Разве что кэшировать определенные данные. Дело курсора — слать правильные (быстрые, ресурсосберегающие) запросы к БД и обеспечивать удобство разработчика.
И насчет предков, Вы даже не представляете сколько людей не умеют правильно работать с СУБД. Не простая это вещь. Так что не "забытая", а недоступная для понимания скорее.
Это даже не психологический вопрос, а общефилософский. Полоса прокрутки — инструмент, который дает определенные возможности. Насколько они нужны? А нужна ли полоса прокрутки при работе с большими файлами в Word. Если еще радикальнее, то Бетховену для написания 9-й симфонии слух оказался не нужен. А Алехину для одновременной игры на 32 досках — зрение.
Но это экстремумы. Резюме правильное. Примерно то же самое — в выводах статьи. Я бы еще добавил, что надо пытаться создавать интерфейсы, которые естественным образом не предполагают возможность пользователю получать большие выборки.
Спасибо за комменты. Вы предлагаете проектировать решения, которые не дают пользователю делать большие выборки. Это звучало и в других комментариях. Как проектировщик полностью с Вами согласен. Но, например, 1С-проектировщики этим не очень заморачиваются. Не заморачиваются этим, например, во ВКонтакте. Обычно, создать удобные решения, использующие ограниченные выборки, можно, но не так просто. Поэтому сейчас интерфейсы, предполагающие просмотр больших таблиц, используются очень часто.
ADO (как и любой другой API работы с СУБД) позволяет реализовать любой вариант работы с табличными данными, в т.ч. все варианты, описанные в статье, вариант, используемый в 1С (есть в комментах) и любой другой вариант.
И, что удивительно, все используют разные варианты — кто во что горазд. Так что вопрос условно решен: всеми по-разному.
Обратите внимание, в статье в принципе рассматриваются только подходы, которые предполагают, что из базы данных считывается только часть данных.
Мысль насчет 100 записей я не совсем понял. ОК, отобразили мы их. Бегунок, разумеется, в конце. Далее сдвинули мы бегунок в середину. Какой с Вашей точки зрения запрос должен пойти в базу данных?
Спасибо за скриншот. Как раз в предыдущем посте хотел написать, что полосу прокрутки вообще бы надо в таком случае убирать. Только место занимает. Очень радикально 1С действует. Особенно учитывая то, что в данном случае можно обойтись и без радикализма. Даже если не идти на компромиссы в части производительности, хоть какую-то полосу прокрутки можно обеспечить.
Скажем так, между 40 записями и одним миллионом есть 999 960 вариантов. И на 10 000 записей, а иногда и на 100 000 очень удобно пользоваться полосой прокрутки.
Идея умной фильтрации интересная. Выбираем запись и далее просим отобразить соседние. Интересно было бы посмотреть реализацию. Хотя, на вскидку, может слишком сложно для пользователя получиться. С нечетким поиском не совсем понял. Но в любом случае нечеткий поиск (пробовал в том же PostgreSQL) — вещь не быстрая.
Подход "последние 100 записей" как раз не позволит показать правильную полосу прокрутки. Откуда же взять общее количество записей? И как быстро и минимально затратно получить записи, например, от 100 до 200 с конца или, хуже с 1000 по 1100-ю. В вопросе 2 как раз и показан способ, как построить интерфейс с быстрой загрузкой, правильной полосой прокрутки и минимальным штрафом на СУБД.
Я уверен (это мой опыт), что диаграммы очень помогают в программной документации (как и текст, и прототипы интерфейсов). Но это тема другой статьи))
Требование Model Visually есть в RUP. Требование итеративной разработки (против которой, насколько я понимаю, направлена Ваша аналогия с движком автомобиля) есть вообще много где. Программисты замечательных продуктов (того же junit5) используют диаграммы в документации.
Ставить все эти очень распространенные паттерны под вопрос можно и полезно, но в рамках значительно более широкого и серьезного обсуждения.
Действительно, включение PlantUML-диаграмм в текст asciidoc — это удобно. Тут больше говорят мои издательские привычки держать спецификации картинок отдельно от документа.
Интересно, тот же RUP говорит: при желании описывайте процесс текстом. И мы этим часто пользуемся. Но в сложных случаях очень часто именно диаграммы позволяют пояснять особенности проектируемой системы стейкхолдерам от пользователей. Об этом также говорится в RUP и это подтверждает опыт.
Опасную иллюзию понимания работы системы может дать и текст и прототипы интерфейсов. Многие пользователи могут вообще не понимать, как будет работать система до того, как ее запустят. На самом деле даже через много лет, после того, как ее запустят.
У меня не получилось нормально рисовать интерфейсы в salt (GUI). Мне проект показался недоработанным. Хотя, возможно, просто не приноровился.
Диаграммы деятельности, мне кажется, надо стараться делать попроще, избегая больших ветвлений, и, в любом случае, подписи на этой диаграмме не совсем ей соответствуют. Но разные есть случаи, предположим надо так
Мой подход был бы следующем
Вместо detach можно сразу поставить stop. Именно в этом примере нижний аппендицит, конечно, не нужен. Но в общем случае можно действовать именно так.
Опять же, в данном конкретном случае можно нарушить все нотации и сделать вот так:
Добавлю к комментарию habradante. Картинки PlantUML можно также объединять при помощи Asciidoctor, тогда у Вас будет прекрасная, хорошо читаемая документация без ежей, которую можно представить и в html, и в pdf.
Я рассматриваю PlantUML в первую очередь как инструмент бизнес-аналитика. Уверен, что этот инструмент не получится нормально использовать для проектирования классов или структуры базы данных, для этого есть другие прекрасные продукты. Но его очень удобно использовать для генерации программной документации.
Например, для визуального проектирования структуры базы данных мы используем инструмент DbSchema (который, собственно, и дает на выходе описание структуры в 2bass). Однако помещать ER-диаграммы в документацию — та еще головная боль. Поэтому для генерации документации мы используем именно PlantUML (фактически, создается несколько диаграмм, каждая на подмножество таблиц базы данных). При проектировании структуры базы данных я даже не задумываюсь о том, как визуально она разложится в диаграмме в документации, я всегда уверен, что это будет красиво и заказчик будет доволен.
Другой вопрос, что при проектировании логической структуры данных для понимания и согласования с заказчиком общих требований к системе я обычно использую именно PlantUML. Т.е. сначала структура сущностей рождается в диаграмме классов PlantUML, далее на основе нее разрабатывается структура базы данных в DbSchema, этот же инструмент используется для поддержания структуры в актуальном состоянии, далее документация по этой структуре генерируется автоматически опять же при помощи PlantUML.
Касательно комментария DmitriyDev. Да, все верно, PlantUML позволяет указывать желаемое направление стрелки (например, -r- или -right-), на самом деле, еще и увеличивать ее длину (например --- будет длиннее, чем --). Но, как я писал в статье, у меня не получилось использовать эту функциональность удобно. Пусть уж PlantUML распределяет элементы, как хочет. Я стараюсь влиять на расположение элементов через их группировку, иногда через порядок их указания в спецификации.
Возможно, там еще какие-то хитрости применены, но, думаю, примерно алгоритм описан верно.
Поэтому вопрос хочется исследовать до конца. Укажите, пожалуйста, о какой версии платформы 1С идет речь. Мы только что выяснили, что по крайней мере в 1С версии 8.2 (web-клиент) и в некоторых последующих версиях полоса прокрутки вообще не используется. Это и объясняет высокую скорость работы. И подтормаживания здесь быть не должно ни на 130 миллионах записей, ни на 130 миллиардах. Если база данных держит такую таблицу (это уже больше аппаратный вопрос), значит и считывание записей по ключевым полям не может тормозить. Возможно, в разных версиях 1С реализован разный алгоритм работы с СУБД.
А курсор сам по себе к производительности добавить ничего не может. Разве что кэшировать определенные данные. Дело курсора — слать правильные (быстрые, ресурсосберегающие) запросы к БД и обеспечивать удобство разработчика.
И насчет предков, Вы даже не представляете сколько людей не умеют правильно работать с СУБД. Не простая это вещь. Так что не "забытая", а недоступная для понимания скорее.
Но это экстремумы. Резюме правильное. Примерно то же самое — в выводах статьи. Я бы еще добавил, что надо пытаться создавать интерфейсы, которые естественным образом не предполагают возможность пользователю получать большие выборки.
ADO (как и любой другой API работы с СУБД) позволяет реализовать любой вариант работы с табличными данными, в т.ч. все варианты, описанные в статье, вариант, используемый в 1С (есть в комментах) и любой другой вариант.
И, что удивительно, все используют разные варианты — кто во что горазд. Так что вопрос условно решен: всеми по-разному.
Мысль насчет 100 записей я не совсем понял. ОК, отобразили мы их. Бегунок, разумеется, в конце. Далее сдвинули мы бегунок в середину. Какой с Вашей точки зрения запрос должен пойти в базу данных?
Идея умной фильтрации интересная. Выбираем запись и далее просим отобразить соседние. Интересно было бы посмотреть реализацию. Хотя, на вскидку, может слишком сложно для пользователя получиться. С нечетким поиском не совсем понял. Но в любом случае нечеткий поиск (пробовал в том же PostgreSQL) — вещь не быстрая.