diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..6f7a6bd --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +.playwright-mcp/ diff --git a/.gitkeep b/.gitkeep new file mode 100644 index 0000000..11b66d2 --- /dev/null +++ b/.gitkeep @@ -0,0 +1 @@ +# .gitkeep file auto-generated at 2026-05-19T19:55:41.811Z for PR creation at branch issue-1-f874e4635d72 for issue https://github.com/ideav/sci/issues/1 \ No newline at end of file diff --git a/README.md b/README.md index 936226f..9dfb740 100644 --- a/README.md +++ b/README.md @@ -1 +1,31 @@ -# sci \ No newline at end of file +# sci + +Материалы и план подготовки научной публикации по модели **IDEAV** и +конструктору **Интеграм** (Integram) — варианту обобщённой Entity–Attribute–Value +(EAV) модели с устранением классических проблем масштабируемости (партиционирование +по диапазонам идентификаторов, индексация, кортежи фиксированной арности). + +Цель — опубликоваться в **Journal of Systems and Software** (Elsevier, Scopus Q1) +или в одном из альтернативных Q1‑изданий из списка целевых журналов. + +## Содержание + +| Документ | Назначение | +|----------|------------| +| [`docs/PLAN.md`](docs/PLAN.md) | Поэтапный план работы до подачи рукописи | +| [`docs/PRIOR-ART.md`](docs/PRIOR-ART.md) | Обзор предшественников и сравнение с IDEAV/Интеграмом | +| [`docs/TARGET-VENUES.md`](docs/TARGET-VENUES.md) | Целевые журналы и конференции с критериями | +| [`docs/PAPER-OUTLINE.md`](docs/PAPER-OUTLINE.md) | Скелет рукописи под требования JSS | +| [`docs/CHECKLIST.md`](docs/CHECKLIST.md) | Чек‑лист готовности к подаче | + +## Источники, послужившие отправной точкой + +* Habr, «Предельная унификация», +* Habr, «Измерения предела возможностей», +* Red‑Gate Simple‑Talk, *Bad CaRMa*, +* Три обсуждения в DeepSeek Chat — ссылки приведены в исходном issue + (см. ideav/sci#1). На момент подготовки документа shared‑страницы DeepSeek + возвращают HTTP 403 для внешних читателей, поэтому их выводы пересказываются + по контексту, известному автору, и помечаются как `(внутренний источник)`. + +Полный текст задачи: ideav/sci#1. diff --git a/docs/CHECKLIST.md b/docs/CHECKLIST.md new file mode 100644 index 0000000..cb0bcba --- /dev/null +++ b/docs/CHECKLIST.md @@ -0,0 +1,82 @@ +# Чек‑лист готовности к подаче + +Отметки в Markdown: `[ ]` — не сделано, `[x]` — сделано. Этот документ — +живой; обновляйте его в каждом PR. + +## Этап 0. Тезис + +- [ ] Зафиксировано каноническое определение IDEAV (расшифровка аббревиатуры). +- [ ] Зафиксирована арность кортежа (квартет / иной). +- [ ] Записан elevator pitch в `docs/THESIS.md`. +- [ ] Перечислены 2–3 проверяемых гипотезы. + +## Этап 1. Обзор предшественников + +- [ ] PRISMA‑lite поиск проведён в IEEE/ACM/Scopus. +- [ ] Каждая запись в `PRIOR-ART.md` имеет BibTeX. +- [ ] Описаны все open‑source конкуренты (NocoDB, Baserow, Directus, Strapi…). +- [ ] Покрыты известные провалы (CaRMa, Magento bloat, и др.). + +## Этап 2. Формальная модель + +- [ ] DDL эталонной схемы в `experiments/schema/`. +- [ ] Псевдокод CRUD‑операций в `experiments/algorithms/`. +- [ ] Опционально: TLA+/Alloy спецификация. +- [ ] Описано отображение IDEAV → реляционная алгебра. + +## Этап 3. Эталонная реализация + +- [ ] `docker compose up` поднимает стек на чистой VM. +- [ ] Smoke‑тесты проходят в CI. +- [ ] Зафиксированы версии PostgreSQL и расширений. +- [ ] Дамп тестовой БД доступен по URL/DOI. + +## Этап 4. Дизайн экспериментов + +- [ ] Документ `experiments/DESIGN.md` готов и заморожен. +- [ ] Подтверждено железо (CPU, RAM, диск, сеть) и его доступность. +- [ ] Baselines настроены и валидированы. +- [ ] Статплан включает sample size, повторы, эффект‑сайз, p‑value. + +## Этап 5. Прогоны + +- [ ] Манифест каждого прогона коммитится в `experiments/results/`. +- [ ] Минимум 3 повтора на условие. +- [ ] Сырые логи зачищены от PII. +- [ ] Воспроизводимость подтверждена контрольным прогоном. + +## Этап 6. Анализ + +- [ ] Ноутбуки в `analysis/` запускаются с одной командой. +- [ ] Все рисунки в `figures/` отсылают к источнику данных. +- [ ] Описаны статистические тесты и ДИ. + +## Этап 7. Драфт + +- [ ] Соответствие шаблону `elsarticle` (single‑column). +- [ ] Abstract ≤ 250 слов. +- [ ] 3–5 Highlights. +- [ ] CRediT для всех авторов. +- [ ] Data Availability Statement готов. +- [ ] Объём ≤ 36 страниц single‑column. + +## Этап 8. Внутренняя ревизия + pre‑print + +- [ ] Ревью от минимум двух внешних читателей. +- [ ] Все блокирующие замечания закрыты. +- [ ] Pre‑print на SSRN, DOI получен. + +## Этап 9. Сабмишн + +- [ ] Cover letter подготовлен. +- [ ] Декларация GenAI / конфликта интересов / финансирования. +- [ ] Архив с supplementary materials готов. +- [ ] Editorial Manager submission подтверждён. +- [ ] Тег релиза в репозитории + Zenodo DOI. +- [ ] План B по альтернативным журналам (см. `TARGET-VENUES.md`). + +## После подачи + +- [ ] `docs/REVIEW-LOG.md` создан и поддерживается. +- [ ] Список вопросов от ревьюеров и план ответов. +- [ ] Сроки ревизий контролируются. diff --git a/docs/PAPER-OUTLINE.md b/docs/PAPER-OUTLINE.md new file mode 100644 index 0000000..ddbb53b --- /dev/null +++ b/docs/PAPER-OUTLINE.md @@ -0,0 +1,92 @@ +# Скелет рукописи под JSS + +Шаблон рукописи, согласованный с требованиями +*Journal of Systems and Software* (Elsevier, `elsarticle` LaTeX, single‑column, +≤ 36 страниц). Заполняется на этапе 7 плана. + +--- + +## Title (рабочее) + +> *IDEAV: A Scalable Quadruple‑Tuple EAV Model and Its Reference Implementation +> in the Integram Low‑Code Platform* + +Альтернативы для bake‑off: + +* «Beyond EAV: Scaling Metadata‑Driven Applications via Partitioned + Quadruples». +* «From Bad CaRMa to Good IDEAV: Re‑examining the Entity–Attribute–Value + Model at Scale». + +## Abstract (≤ 250 слов) + +Шаблон секций: + +1. **Context** — какие реальные задачи решают EAV‑подобные платформы и почему + они известны как анти‑паттерн. +2. **Objective** — формализовать IDEAV как четырёхкортежный вариант EAV с + диапазонным партиционированием и показать, что он устраняет основные + причины деградации. +3. **Method** — эмпирическое сравнение на нагрузке 10⁹–10¹⁰ записей против + четырёх baselines (3НФ, JSONB, MongoDB, ClickHouse). +4. **Results** — конкретные количественные показатели (latency p95, throughput, + стоимость эволюции схемы) с ДИ. +5. **Conclusion** — границы применимости и условия, при которых IDEAV + предпочтительнее альтернатив. + +## Highlights (3–5 пунктов) + +* IDEAV формализован как кортеж арности 4 с диапазонным партиционированием. +* На объёме 31 млрд записей деградация insert ниже 5 % (см. этап 5). +* Ad‑hoc запросы p95 в пределах 2× от 3НФ‑аналога при произвольной схеме. +* Эталонная реализация (Интеграм) опубликована под MIT/Apache 2. +* Условия применимости и анти‑паттерны выписаны явно (когда IDEAV не нужен). + +## Структура секций + +| № | Секция | Содержание | +|---|--------|------------| +| 1 | Introduction | Мотивирующий пример, исследовательские вопросы (RQ1–RQ3), вклад. | +| 2 | Background and Related Work | EAV в EHR, провалы (CaRMa, Magento bloat), low‑code платформы — см. `PRIOR-ART.md`. | +| 3 | The IDEAV Model | Формальное определение, инварианты, операции, отображение в реляционную алгебру. | +| 4 | Reference Implementation: Integram | Архитектура, схема, индексы, партиционирование, эволюция схемы. | +| 5 | Experimental Design | Гипотезы, переменные, baselines, нагрузка, метрики, статплан. | +| 6 | Results | Графики, таблицы, статтесты, эффект‑сайз. | +| 7 | Discussion | Внутренняя/внешняя валидность, threats to validity, ниши применимости. | +| 8 | Conclusion and Future Work | Что получилось, что осталось, дорожная карта. | +| | Author Contributions | По CRediT. | +| | Data Availability Statement | DOI Zenodo, URL репозитория. | +| | Acknowledgments | Спонсоры, со‑авторы, прокси‑ревьюеры. | +| | References | BibTeX, авто‑форматирование. | + +## Исследовательские вопросы (черновик) + +* **RQ1.** Можно ли формализовать IDEAV так, чтобы каждая операция CRUD + имела предсказуемую асимптотику по числу хранимых записей? +* **RQ2.** Как IDEAV ведёт себя по latency/throughput/disk на нагрузке + 10⁹–10¹⁰ записей по сравнению с 3НФ, JSONB, документной и колоночной СУБД? +* **RQ3.** Какова амортизированная стоимость эволюции схемы (добавление + атрибута / типа / индекса) на работающей системе и в каких случаях она + ниже, чем у классической 3НФ? + +## Cover Letter + +Подготовить отдельный файл `docs/COVER-LETTER.md` на этапе 9. Краткие +ингредиенты: + +* Почему именно JSS (соответствие скоупу «systems & software»). +* Что нового по сравнению с предыдущими работами авторов и других групп. +* Подтверждение, что работа не подавалась параллельно. +* Декларация о GenAI‑инструментах, конфликте интересов, источниках + финансирования. + +## Воспроизводимость + +Артефакты к моменту подачи: + +* Репозиторий GitHub с тегом релиза (`vX.Y.Z`). +* DOI на Zenodo (CI workflow `release-to-zenodo.yml`). +* Скрипты воспроизводства бенчмарков (`reproduce.sh`) с фиксацией версий. +* `DATA_AVAILABILITY.md` — описание датасета (генерация / реальные данные). + +В тексте статьи — ссылка на DOI Zenodo, а не на «живой» GitHub. diff --git a/docs/PLAN.md b/docs/PLAN.md new file mode 100644 index 0000000..9804b4d --- /dev/null +++ b/docs/PLAN.md @@ -0,0 +1,190 @@ +# План публикации: IDEAV / Интеграм → JSS (Elsevier, Q1) + +> Цель: подать оригинальную статью, описывающую модель IDEAV и её эталонную +> реализацию в конструкторе **Интеграм**, с эмпирической оценкой пределов +> производительности и сравнением с альтернативами, в Journal of Systems and +> Software (или в одном из альтернативных Q1‑изданий, см. +> [`TARGET-VENUES.md`](TARGET-VENUES.md)). + +Работа разбита на **10 этапов**. Каждый этап имеет вход, выход и критерий +готовности (Definition of Done, DoD). Этапы можно частично параллелить — +см. колонку «зависимости». + +--- + +## Этап 0. Снять неоднозначности и зафиксировать тезис + +| Поле | Значение | +|------|----------| +| Вход | Issue ideav/sci#1, исходные статьи на Habr, обсуждения в DeepSeek. | +| Выход | Документ `docs/THESIS.md` объёмом 1–2 страницы: основное утверждение, целевая аудитория, three‑sentence pitch. | +| DoD | Тезис выдерживает «elevator test» — соисследователь может пересказать его за минуту без обращения к источникам. | +| Зависимости | — | + +Ключевые вопросы, которые нужно закрыть до старта: + +1. **Что именно расшифровывается за аббревиатурой IDEAV?** В источниках встречается + формулировка «Identifier — Domain — Entity — Attribute — Value» и просто + «Entity‑ID‑Attribute‑Value». Зафиксировать каноническое определение и арность + кортежа (квартет / квинтет). +2. **Что такое «Интеграм»?** Это эталонная реализация (open‑source конструктор) + или коммерческий продукт. От ответа зависит дальнейшая стратегия открытых данных. +3. **Чем работа отличается от классической EAV?** Сформулировать одно‑два + технических отличия, которые потенциально могут быть верифицированы экспериментом + (партиционирование по диапазонам ID, индексные структуры, разделение + schema/data, типизация значений и т. д.). +4. **Где предел?** Сформулировать гипотезу о масштабируемости: размер БД, + throughput insert/select, latency p95/p99, деградация в зависимости от объёма. + +--- + +## Этап 1. Систематический обзор предшественников + +| Поле | Значение | +|------|----------| +| Вход | Список «других похожих попыток» из issue + наш каталог [`PRIOR-ART.md`](PRIOR-ART.md). | +| Выход | Расширенный систематический обзор (SLR) по PRISMA‑lite в `docs/related-work/`. | +| DoD | Покрыты три кластера: (а) классическая EAV в EHR, (б) EAV‑провалы (CaRMa, Magento‑bloat, Inner Platform Effect), (в) современные low‑code/no‑code платформы с пользовательскими сущностями. Каждый источник имеет BibTeX‑запись. | +| Зависимости | Этап 0. | + +Подсказки по поиску: + +* IEEE Xplore / ACM DL / Scopus — запросы: `"entity attribute value" model`, + `EAV scalability`, `flexible schema relational`, `metadata-driven application`, + `low-code platform scalability`. +* Серая литература: Tom Kyte (Oracle blog), Joe Celko, Bill Karwin + «SQL Antipatterns» (раздел Entity‑Attribute‑Value), Eric Evans DDD. +* Каталог низкокод‑платформ: Bubble, Retool, Airtable, NocoDB, Baserow, + Directus, AppSheet, Salesforce Lightning Platform — для каждой описать, + как они хранят пользовательские сущности. + +--- + +## Этап 2. Формализация модели IDEAV + +| Поле | Значение | +|------|----------| +| Вход | Тезис (этап 0), обзор (этап 1). | +| Выход | Раздел «Model» рукописи: формальные определения, аксиомы, инварианты, отображение на реляционную алгебру. | +| DoD | Модель описана в нотации, пригодной для рецензента: кортеж, схема, операции CRUD, операции выборки, переходы между состояниями. Есть теорема о корректности отображения IDEAV → реляционная модель. | +| Зависимости | Этап 0. | + +Технические артефакты: + +* DDL эталонной схемы PostgreSQL (`experiments/schema/`). +* Псевдокод операций (`experiments/algorithms/`). +* Опционально — TLA+/Alloy‑модель для проверки инвариантов (`experiments/spec/`). + +--- + +## Этап 3. Эталонная реализация и репозиторий артефактов + +| Поле | Значение | +|------|----------| +| Вход | Формальная модель (этап 2). | +| Выход | Воспроизводимая инсталляция Интеграма (Docker Compose / Helm), скрипты загрузки данных. | +| DoD | На чистой VM с одной командой поднимается стек с примером БД и пройденными smoke‑тестами. README содержит SHA‑hash датасетов. | +| Зависимости | Этап 2. | + +Это требование Open Science из политики JSS — без публичного артефакта статья +с эмпирикой имеет высокий риск отказа уже на desk‑review. + +--- + +## Этап 4. Дизайн экспериментов + +| Поле | Значение | +|------|----------| +| Вход | Гипотезы из этапа 0 («где предел»). | +| Выход | Документ `experiments/DESIGN.md`: переменные (factor / treatment / response), уровни нагрузки, baselines, конфигурация железа, метрики, статистический план. | +| DoD | Дизайн обсуждён минимум одним внешним экспертом (DBA или software engineer researcher). Все параметры заморожены до запуска. | +| Зависимости | Этап 3. | + +Минимальный набор baselines: + +1. Классическая 3НФ‑схема PostgreSQL. +2. JSONB‑колонка в PostgreSQL (semi‑structured). +3. Документная СУБД (MongoDB / Couchbase). +4. Колоночная СУБД для аналитической части (ClickHouse). +5. IDEAV / Интеграм (наш кандидат). + +Метрики: throughput insert, latency select p50/p95/p99, размер БД на диске, +амортизированная стоимость добавления нового атрибута, время «холодного» бэкапа. + +--- + +## Этап 5. Запуск экспериментов и сбор данных + +| Поле | Значение | +|------|----------| +| Вход | Замороженный дизайн (этап 4). | +| Выход | Сырые логи и агрегированные таблицы результатов в `experiments/results//`. | +| DoD | Каждый прогон сопровождается манифестом (версия кода, hash датасета, hw‑профиль). Результаты воспроизводятся при повторном прогоне в пределах заявленной погрешности. | +| Зависимости | Этап 4. | + +--- + +## Этап 6. Анализ и визуализация + +| Поле | Значение | +|------|----------| +| Вход | Результаты этапа 5. | +| Выход | Jupyter‑ноутбуки + сгенерированные графики (`figures/`), таблицы со значимыми отличиями (Mann–Whitney / Wilcoxon, эффект‑сайз). | +| DoD | Каждый рисунок имеет caption, ссылку на ноутбук, исходные данные. Все статистические утверждения снабжены p‑values и доверительными интервалами. | +| Зависимости | Этап 5. | + +--- + +## Этап 7. Драфт рукописи под JSS + +| Поле | Значение | +|------|----------| +| Вход | Артефакты этапов 1–6. | +| Выход | Полный draft в Elsevier `elsarticle` LaTeX по [`PAPER-OUTLINE.md`](PAPER-OUTLINE.md). | +| DoD | Заполнены все обязательные секции (Abstract ≤ 250 слов, 3–5 Highlights, Author Contributions по CRediT, Data Availability). Объём ≤ 36 страниц single‑column. | +| Зависимости | Этап 6. | + +--- + +## Этап 8. Внутренняя ревизия и pre‑print + +| Поле | Значение | +|------|----------| +| Вход | Draft этапа 7. | +| Выход | Финальный pre‑print, выложенный на SSRN (JSS поддерживает SSRN без ущерба процессу), DOI получен. Список ревью‑комментариев закрыт. | +| DoD | Минимум два независимых читателя из целевой аудитории дали письменные отзывы; критические замечания закрыты или явно отклонены с обоснованием. | +| Зависимости | Этап 7. | + +--- + +## Этап 9. Подача в JSS и параллельные действия + +| Поле | Значение | +|------|----------| +| Вход | Финальный pre‑print + cover letter. | +| Выход | Сабмишн в Editorial Manager JSS, номер рукописи, статус «With Editor». Параллельно — публикация артефактов на Zenodo с DOI и тегом релиза в этом репозитории. | +| DoD | Подтверждение от редакции получено. Бэкап‑план для альтернативных журналов готов (см. [`TARGET-VENUES.md`](TARGET-VENUES.md)). | +| Зависимости | Этап 8. | + +После подачи: вести `docs/REVIEW-LOG.md` с историей рецензий и нашими ответами. + +--- + +## Сводная таблица сроков (рекомендация) + +| Этап | Время, нед. | Параллельность | +|------|-------------|----------------| +| 0 | 1 | — | +| 1 | 3 | Параллельно с 2 | +| 2 | 3 | Параллельно с 1 | +| 3 | 2 | После 2 | +| 4 | 2 | После 3 | +| 5 | 4 | — | +| 6 | 2 | Частично параллельно с 5 | +| 7 | 4 | — | +| 8 | 2 | — | +| 9 | 1 | — | +| **Итого** | **≈ 20 недель** | | + +Реальные сроки зависят от доступности железа и со‑авторов, см. +[`CHECKLIST.md`](CHECKLIST.md) для оперативного отслеживания. diff --git a/docs/PRIOR-ART.md b/docs/PRIOR-ART.md new file mode 100644 index 0000000..d6d6c86 --- /dev/null +++ b/docs/PRIOR-ART.md @@ -0,0 +1,102 @@ +# Обзор предшественников: EAV, «гибкие» схемы и low‑code + +Этот документ — стартовый каталог работ, относительно которых должна +позиционироваться публикация по IDEAV/Интеграму. Каждая запись содержит +краткое описание, домен, источник и роль для нашей статьи +(`позитивный baseline`, `негативный пример`, `смежная область`). + +--- + +## 1. Классические реализации EAV в медицине + +| Система | Описание | Источник | Роль | +|---------|----------|----------|------| +| Regenstrief EMR | Один из первых EMR, ввёл (Patient, Attribute, Timestamp, Value). | McDonald, 1970s; Wikipedia EAV | смежная область | +| HELP (LDS Hospital → 3M) | Клиническая БД, коммерциализированная 3M. | Warner et al. | смежная область | +| TMR (Stead & Hammond) | EAV для устойчивого хранения клинических данных. | Stead, Hammond | смежная область | +| Columbia‑Presbyterian system | Первая EAV‑надстройка над реляционным движком. | Friedman, Hripcsak | смежная область | +| TrialDB | Open‑source менеджмент клинических исследований; несколько EAV‑таблиц по типам. | Nadkarni et al. | смежная область | +| i2b2 | EAV‑data mart для биомедицинских исследований. | Murphy, Kohane | смежная область | +| SenseLab | Нейронаучные данные на EAV/CR. | Nadkarni, Marenco | смежная область | +| VistA / MUMPS | Медсеть VA США, иерархическая БД на MUMPS — функциональный аналог EAV. | US Dept. of Veterans Affairs | смежная область | +| Oracle Clinical, ClinTrial | Коммерческие платформы клинических исследований. | Oracle Health Sciences | смежная область | +| Epic «Flowsheets» | Конфигурируемые power‑user атрибуты. | Epic Systems | смежная область | +| Cerner subschema | EAV‑подсхема в коммерческом EHR. | Cerner / Oracle | смежная область | + +--- + +## 2. Известные провалы и «анти‑паттерны» + +| Случай | Что было сделано | Чем закончилось | Источник | Роль | +|--------|------------------|----------------|----------|------| +| **CaRMa / Vision** (1990‑е, спутниковое ТВ) | Единая таблица `DATA` на 240+ колонок, всё хранится как EAV‑подобный универсум; индексов больше, чем данных. | Деградация performance, невозможность сопровождения, проект закрыт в течение нескольких месяцев после go‑live. | Red‑Gate Simple‑Talk, *Bad CaRMa* | негативный пример | +| **Magento 1.x EAV bloat** | Каталоги товаров на EAV (eav_attribute, catalog_product_entity_*). | Замедление каталога при росте SKU, миграция на flat tables в Magento 2 как стандарт оптимизации. | Документация Magento, многочисленные блоги | негативный пример | +| **Drupal 7 → 8 field storage** | Гибкое хранение полей через field tables (по сути EAV). | Замена на сущностные таблицы и BC‑прослойку в Drupal 8/9 ради производительности. | Drupal core changelog | смешанный | +| **Tom Kyte (Oracle) на EAV** | Жёсткая позиция: «избегать в business‑сценариях всегда». | Аргументы про планы запроса, индексирование, безопасность. | AskTom, блог Oracle | негативный пример | +| **Bill Karwin, SQL Antipatterns** | Глава «Entity‑Attribute‑Value» как анти‑паттерн. | Каталог типичных грабель и альтернатив. | Pragmatic Bookshelf, 2010 | негативный пример | +| **Inner Platform Effect** | Общий анти‑паттерн «строим СУБД внутри СУБД». | Описан в коммьюнити C2 wiki и в Karwin. | C2 wiki, Wikipedia | негативный пример | + +--- + +## 3. Современные платформы с пользовательскими сущностями + +Эти системы решают ту же задачу, что и Интеграм, но другими средствами. +Их стоит описать и сравнить по: модели хранения, способу эволюции схемы, +порогу масштабирования, лицензии. + +| Платформа | Модель хранения | Open source | Замечания | +|-----------|----------------|-------------|-----------| +| Airtable | Проприетарный движок поверх MySQL (по слухам). | нет | benchmark недоступен. | +| Bubble | Проприетарная схема. | нет | хороший пример визуального low‑code. | +| Retool | Тонкая обёртка над пользовательскими БД. | частично | не хранит «свои» сущности. | +| Salesforce custom objects | Универсальная EAV‑подобная схема в Oracle (известна по утечкам/реверсу). | нет | классический индустриальный success‑case EAV в масштабе. | +| **NocoDB** | Метаданные + проксирование к пользовательскому SQL. | да (AGPL) | прямой open‑source конкурент Airtable. | +| **Baserow** | PostgreSQL с динамическим DDL (создаёт реальные таблицы). | да (MIT) | альтернативный подход — «настоящие» таблицы. | +| **Directus** | Headless CMS поверх любой SQL‑БД. | да (BSL) | работает со «своими» таблицами пользователя. | +| **AppSheet** | Поверх Google Sheets / Cloud SQL. | нет | важно как индустриальная точка отсчёта. | +| **Knack / Caspio** | Проприетарный SaaS. | нет | EAV‑образное хранение по описаниям. | +| **Strapi** | Headless CMS, динамические content types. | да (MIT) | другая ниша, но релевантный low‑code. | + +Для каждого из open‑source кандидатов в этап 4 плана можно поставить +эксперимент в одинаковых условиях нагрузки. + +--- + +## 4. Академические работы, на которые имеет смысл ссылаться + +* **Nadkarni, P. M., Marenco, L., Chen, R., Skoufos, E., Shepherd, G., Miller, P.** + *Organization of heterogeneous scientific data using the EAV/CR + representation.* JAMIA, 1999. +* **Nadkarni, P. M., Brandt, C.** *Data Extraction and Ad Hoc Query of an + Entity–Attribute–Value Database.* JAMIA, 1998. +* **Dinu, V., Nadkarni, P.** *Guidelines for the effective use of + entity–attribute–value modeling for biomedical databases.* JBI, 2007. +* **Anhøj, J.** *Generic design of Web‑based clinical databases.* JMIR, 2003. +* **Codd, E. F.** *A Relational Model of Data for Large Shared Data Banks.* + CACM, 1970 — фундамент, от которого мы отходим. +* **Karwin, B.** *SQL Antipatterns: Avoiding the Pitfalls of Database + Programming.* Pragmatic Bookshelf, 2010. +* **Sadalage, P., Fowler, M.** *NoSQL Distilled.* Addison‑Wesley, 2012 — + для позиционирования относительно document/columnar/KV. +* **Stonebraker, M.** *Schema Later? No Way!* — заметки про schema‑less. +* **Pavlo, A. et al.** *What's Really New with NewSQL?* SIGMOD Record, 2016. +* **Floratou, A. et al.** *Can the elephants handle the NoSQL onslaught?* + VLDB, 2012 — методология бенчмарков смешанных нагрузок. + +--- + +## 5. Что из этого собственно «новое» в IDEAV / Интеграме? + +Это — самый важный раздел, который пока требует доработки автором. Ниже +рабочая гипотеза, которую нужно подтвердить или опровергнуть на этапе 0 +плана: + +> IDEAV отличается от классической EAV (а) фиксированной арностью кортежа +> (квартет вместо тройки), что даёт возможность партиционировать данные по +> диапазонам идентификаторов и поддерживать B‑Tree‑индексы постоянной +> высоты; (б) разделением *metadata* и *data* на уровне физического +> хранения; (в) типизацией значений на уровне колонок (а не строк), что +> снимает классическую проблему string‑coercion и потери индексируемости. + +Если эта гипотеза верна, то в статье есть **измеримое** утверждение — +именно его и нужно эмпирически проверить на этапе 5 плана. diff --git a/docs/TARGET-VENUES.md b/docs/TARGET-VENUES.md new file mode 100644 index 0000000..f3e20db --- /dev/null +++ b/docs/TARGET-VENUES.md @@ -0,0 +1,75 @@ +# Целевые издания + +Основная цель — **Journal of Systems and Software** (Elsevier). +В таблице ниже — приоритезированный список с альтернативами на случай +отказа или несоответствия скоупа. + +## Основной таргет + +### Journal of Systems and Software (JSS) + +* Издатель: **Elsevier**. +* Индексация: **Scopus Q1**, Web of Science (SCIE). +* Формат: full‑length research (≤ 36 страниц single‑column / 18 двух‑колоночных), + Applied Research Reports, Practitioner Insights (≤ 4 стр., первый автор из + индустрии), New Ideas and Trends Papers (NITP), систематические обзоры, + репликации. +* Обязательно: Abstract ≤ 250 слов, 3–5 Highlights, ключевые слова (1–7), + Author Contributions (CRediT), Data Availability Statement, депозит данных + и кода в публичный репозиторий. +* Этический режим: декларация использования GenAI; никаких GenAI‑сгенерированных + изображений; single‑blind review. +* Open Access: опциональный (через APC), либо subscription + Share Link. +* Pre‑print: разрешён, рекомендуется SSRN. +* Submission portal: Editorial Manager. + +Почему подходит нам: + +* Скоуп явно включает «системы и ПО», что покрывает базу данных + платформу. +* Принимаются NITP — хорошая запасная подача для «New Ideas» с + предварительными результатами. +* Поддержка систематических обзоров — можно отдельной работой опубликовать + результат этапа 1. + +## Запасные Q1‑журналы (Elsevier / Springer / IEEE / ACM) + +| Журнал | Издатель | Профиль | Когда выбирать | +|--------|----------|--------|---------------| +| **Information Systems** | Elsevier | Базы данных, информационные системы | Если ревью JSS сочтёт работу слишком «db‑heavy». | +| **Information and Software Technology (IST)** | Elsevier | Software engineering, эмпирика | Близкий аналог JSS, удобный fallback. | +| **Empirical Software Engineering (EMSE)** | Springer | Эмпирические исследования | Если усилим статистическую часть. | +| **Data & Knowledge Engineering (DKE)** | Elsevier | Моделирование данных | Хорошо ложится на формализацию модели. | +| **The VLDB Journal** | Springer | СУБД, performance | Если бенчмарки станут основным вкладом. | +| **ACM Transactions on Database Systems (TODS)** | ACM | Фундаментальная теория БД | Долгий цикл, но высокий престиж. | +| **Software: Practice and Experience** | Wiley | Инженерный опыт реальных систем | Удобно для «case study Интеграма». | +| **IEEE Transactions on Knowledge and Data Engineering (TKDE)** | IEEE | Знания + данные | Если усилим knowledge‑модель. | + +## Конференции‑альтернативы (если предпочтём conference‑first) + +* **VLDB** (industry / research track) — для эмпирических работ с + сильными бенчмарками. +* **ACM SIGMOD** — теория и индустрия БД. +* **IEEE ICDE** — Data Engineering, проще принимает industry‑case‑studies. +* **EDBT** — европейская площадка, более лояльный цикл. +* **ICSE / ESEC‑FSE** (industry track) — если статья про инженерный опыт + платформы Интеграм. + +## Локальные журналы для русскоязычной аудитории (промежуточные публикации) + +* **Программирование** (РАН), Q2/Q3 — для теоретической части. +* **Программные продукты и системы** — для case study. +* Habr (научно‑популярная публикация) — уже частично сделано; полезно как + предварительная апробация перед научной подачей. + +## Декомпозиция: одна тема → несколько публикаций + +Чтобы не «терять» материал в одной статье, разумная декомпозиция: + +1. **Systematic Mapping Study** по EAV‑подобным платформам → IST/EMSE. +2. **Formal Model + Reference Implementation** (IDEAV/Интеграм) → JSS. +3. **Empirical Study at Scale** (31B records, etc.) → VLDB Journal / DKE. +4. **Industry Case Study** → Software: Practice and Experience. + +Это даёт три‑четыре статьи из одного исследовательского ядра без +self‑plagiarism, если каждая фокусируется на собственном исследовательском +вопросе и явно ссылается на остальные.