У меня накопилось несколько баз данных с векторными изображениями, Это векторные контуры створок диатомовых водорослей, крючков паразитических червей моногеней и векторные траектории движения динофлагеллят Oxyrrhis marina.

Базы лежат, пыляться и нет никакой нормальной возможности просмотреть их содержимое в онлайне. Отсюда и родилась идея о создании (универсального) веб-приложения для просмотра векторного содержимого баз.

Назвал это проект «Три вэ».

Быстро сформулировал задачу и требования к ней.

Дано: несколько баз данных, содержащих векторные модели форм микроорганизмов, их частей и траекторий движения.

Необходимо: создать веб-приложения для онлайн просмотра векторных моделей.

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

Получилось очень куцо.

Потом прогнал текст через нейросеть с просьбой добавить деталей.

Оказалось, что за простыми формулировками скрывается несколько неотвеченных вопросов и функций, которые я подразумеваю, но не актуализирую в явном виде.

Ниже — ответ нейросети.

Чтобы сделать требования более четкими и полными, предлагаю структурировать их по следующим категориям:

1. Общие требования

• Цель приложения: Разработать веб-приложение для онлайн-просмотра векторных моделей микроорганизмов, хранящихся в нескольких базах данных.
• Целевая аудитория: Ученые, исследователи в области микробиологии, студенты (или уточнить).
• Ключевые функции:
  • Подключение к различным базам данных с векторными моделями.
  • Просмотр моделей с минимальным набором функций (например, визуализация, масштабирование, вращение).
  • Возможность расширения функциональности (например, добавление аннотаций, фильтров, экспорта).

2. Функциональные требования

• Подключение к базам данных:
  • Поддержка различных типов баз данных (например, SQL, NoSQL, файлы).
  • Унифицированный API или адаптер для подключения новых баз данных без изменения кода приложения.
  • Поддержка безопасного подключения (аутентификация, шифрование данных).

• Просмотр моделей:
  • Визуализация векторных моделей в 2D/3D (указать форматы, например, STL, OBJ, или другие).
  • Интерактивные функции: вращение, масштабирование, панорамирование.
  • Отображение метаданных моделей (например, название микроорганизма, источник, описание).

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

• Дополнительные функции (если применимо):
  • Фильтрация/поиск моделей по параметрам (например, тип микроорганизма, дата создания).
  • Экспорт моделей или их визуализаций (например, в PNG, PDF).

3. Нефункциональные требования

• Производительность:
  • Поддержка загрузки моделей объемом до [указать объем, например, 100 МБ] за разумное время (например, < 5 секунд).
  • Оптимизация для работы с большими наборами данных.

• Совместимость:
  • Поддержка современных браузеров (например, Chrome, Firefox, Safari, Edge).
  • Адаптивный дизайн для работы на десктопах и мобильных устройствах (или уточнить).

• Безопасность:
  • Защита данных при передаче (например, HTTPS).
  • Контроль доступа к базам данных (например, через OAuth или токены).

• Масштабируемость:
  • Возможность обработки подключения новых баз данных без значительных изменений в архитектуре.

• Доступность:
  • Поддержка стандартов доступности (например, WCAG 2.1).

4. Технические требования

• Технологический стек (рекомендации, если не указан):
  • Фронтенд: JavaScript/TypeScript с использованием библиотек для 3D-визуализации (например, Three.js, Babylon.js).
  • Бэкенд: Node.js, Python (FastAPI/Flask) или другой фреймворк для работы с базами данных.
  • Базы данных: Поддержка SQL (PostgreSQL, MySQL) и/или NoSQL (MongoDB).

Форматы данных:

• Указать поддерживаемые форматы векторных моделей (например, STL, OBJ, или специализированные биоинформатические форматы).

• API:
  • REST или GraphQL для взаимодействия с базами данных.
  • Документация API (например, с использованием Swagger/OpenAPI).

5. Ограничения и предположения

• Ограничения:
  • Сроки разработки (например, 3 месяца).
  • Бюджет (если есть).
  • Ограничения по поддерживаемым устройствам/браузерам.

• Предположения:
  • Базы данных имеют стандартные API или доступ через SQL-запросы.
  • Пользователи имеют базовые навыки работы с веб-приложениями.

Есть над чем подумать.

— Элементарно, Ватсон.

SELECT * FROM table ORDER BY RANDOM() LIMIT num_records_to_select

— num_records_to_select заменить на необходимое количество случайных записей.
— Шерлок, глубина ваших познаний не сравниться ни с какой энцикопедией.
— Бросьте, Ватсон, я просто много читаю.

SQLite быстр с индексами, а DuckDB быстр без них

DuckDB does not seem to work with indices as well as SQLite does but is blazingly fast when scanning large parts of the table.

SQLite is great at using indices but takes its time when it has to look at the whole table.

Benchmarking DuckDB vs SQLite for Simple Queries 

Из статьи в Википедии о Викиданных

Викиданные — это база разнообразных лексических концепций, которые могут прочитать как люди, так и машины. Фактически это база для обучения машин человеческим понятиям.

Работает так: мы активно пишем статьи, семантически размечаем приведенные в тексте понятия, а викиботы их вытягивают и заносят в базу. Затем эти данные специальные алгоритмы используют для обучения нейросетей, с которыми мы потом и взаимодействуем.

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

Викибаза — это набор программ, позволяющие извлекать и работать с данными из Викиданных.

Все это открыто и бесплатно. Ну то есть поддержка софта, базы и серверов оплачивается специальными фондами (там ах-ные суммы), а все, кто данные вносят, делают это открыто и бесплатно)