mayton2019

Обычно счет хранится в строго одной валюте. Если пользователь хочет оперировать разными
валютами то он заводит разные счета.

Когда говорят о базе данных, то 99% имеется в виду классическая реляционная БД типа Postgres/MySQL e.t.c.
Такие базы данных создавались для эффективного соединения кортежей и сортировок. Длина DataRow
при этом обычно не больашя (до 8К целый блок таких строк). Эта цифра имеет корни еще в 20м веке.
И если заставить их хранить html (обычно 5-100К) то такая деятельность может быть не очень
удобная для БД. Это как микроскопом гвозди забивать. Очень умная система будет использоваться как
файловое хранилище. Возникает идея - просто взять что-то ориентированное на файлы. Например S3,
BlobStorage, GoogleDrive. Это было-бы дешевле с точки зрения стоимости владения и бэкап делать
проще.

Я понимаю что мы живем в странное время, когда вместо расчета в калькуляторе - запускают гугл или вместо
расчета в MathCad спрашивают ChatGpt, но все-таки программист должен быть немного хозяйственник
и должен брать простые и дешевые решения там где они достаточны.

Вариант

_     | M | X | L
------+---+---+----
Red   |   | Y | Y
Green | Y |   |

Женщина, некурящяя, нет детей и т.д

В подобного рода заданиях совершенно невозможно сесть и написать ТЗ "от и до".
Здесь практика и эксплуатация будет гораздо важнее всей реляционной теории или шаблонов разработки.
Теория говорит что EAV подходит. Но практически в больших базах EAV не работает потому что он неудобен
и работа с ним идет медленно.

Практика применения DBMS уже отказалась от полной нормализации в классическом виде 3-4-5-6НФ
и уже ей не следуют. Postgresql к примеру позволяет завести JSON поле и туда можно положить
такие сложные атрибуты как

пол = женщиа (феминистика)
статус = вдова
прицеп = 5 детей
курит = нет
любит бухнуть = да но по праздникам
предпочтения в сексе = легкий БДСМ и вынос мозга мужчинам

И эти атрибуты ПРОИНДЕКСИРОВАТЬ (!) средствами Postgres и искать гораздо быстрее чем по EAV.

Возможные аномалии возникающие в следствие денормализации мы можем отдельно обсудить.
Но 99% они решаются не технически а по бизнесу. Просто договариваемся что вот так и так дескыть
переименовать атрибуты мы не можем. Принципиально невозможно но и пофиг. Задача не требует такого.

Успех мероприятия будет зависеть от двух факторов.
1) Успеете ли вы грузить трафик? Тут я думаю будет все ОК при использовании TimeSeriesDB.
2) Успеете ли вы делать их анализ? И что за анализ? Нужно ли вам для анализа видеть консистентность
между всех приборов? Что за сложные типы данных? Как они будут участвовать в запросе.

Я не очень понимаю зачем здесь тема БД выпячивается наперед. Шаблон Retry используется очень широко.
И это не к БД относится а к приложению. Мы использовали обычно Guava Retrying with exponential back-off
вот как в примерах пишут https://github.com/rholder/guava-retrying и это примениме не только к БД
а к любым внешним API (Rest/SOAP e.t.c.). Эта механика работае почти везде. Ей много лет и она
воплощена многих сетевых протоколах а не только в приложениях.

По поводу настроек БД. Я могу рассказать про Oracle. Update использует специальный неблокирующий
синтаксис NOWAIT
SELECT .... FOR UPDATE NOWAIT;
который мгновенно возвращает ошибку если не удалось захватить сет строк для обновления. Это подходит
для работы с UI и толстым клиентом например или с веб клиентом.

Например для джоба которы должен работать ночью и взяв например
1000 клиентов или фирм и обработать - предпочтителен подход блокировки всего курсора
SELECT .... FOR UPDATE;.
В этом случае другие джобы будут стоять в ожидании.

А для дневной OLTP активности лучше брать корткие операции с NOWAIT. Проконсультируйтесь с вашей
документацией по вашей БД поддерживается ли неблокирующая операция.

Еще посмотрите видео от Филиппа Дельгядо. Он рассказывал как работали с очередями в Postgres,
там есть интересные режимы блокировок когда не "все или ничего" а есть какой-то компромиссный
режим.

Вообще Retry и защита от перегрузок это броня и снаряд. Как DDOS. Если вы с одной стороны внедряете Retry то с другой
стороны люди начинают плакать и стонать от ваших ретраев до тех пор пока не поставят
вам троттлер или аварийный размыкатель.

Короче думайте о последствиях.

Поскольку нет никаких больше требований. У нас имеется типичная документно-ориентированная БД.
Рецепты. Ингредиенты не специфицированы. Могут быть любые.

Лучше всего здесь подходит MongoDb. И поиск по ингредиентам нормально сработает.
Одна таблица. Просто и изящно.

Семантические графовые базы данных скорее всего подходят под данную задачу. Типа RDF/Semantic Web.
В качестве языка запросов там могут быть использованы SparQL. В качестве платформы хранения.... а чорт
его знает. Там много форматов. И XML и JSON и есть бинарники и JDBC адаптеры.

Это вообще серебрянная пуля которая везде подходит. Даже реляционки можно также представить. Со своими
накладыми но можно.

Но есть несколько мыслей почему их применение может быть неудобным. Первая. Например - знания о том
как все внутри устроено - будут только у 1 человека. У создателя этой базы. И никто кроме автора
в этой базе ничего не найдет.

Вторая. В эпоху умных чятов такие базы знаний умерли очень быстро. Вернее сказать их полезность
сильно девальвировала. В 20м веке в такие базы много вкладывали. Делали ставку на то что системы
со строгими правилами позволят выводить новые правила и факты. Но не сбылось.

Возможно я ошибаюсь и автору нужно на самом деле другое? Что другое? Ну просто какой-то язык
разметки типа markdown language или вообще confluence где можно макросами расширить функционал
и просто делать ссылки на формулы. И может быть это автору будет достаточно.

Вобщем для более глубокого понимания хотелось-бы чтоб автор просто привел парочки примеров. Может
там реально все проще.

famsssss это ETL с нормализацией. Задача - типичная.
У тебя должен быть примерно такой план действий.

1) Таблицы vak, ring, mdb, cat, spec нужно загрузить в БД как есть. В денормализованном виде. Если они лежат в excel - то сохранить их как CSV формат. Далее дело техники. Можете задать другой вопрос в qna по поводу того как их грузить.

2) Надо нарисовать реляционную модель. Это примерно то что ты рисуешь в картинке но нужно рисовать от сущности-связи а не от того какие файлы даны. Например есть сущность ISNN. У нее есть какие-то атрибуты. Они возможно опциональные. Но они должны быть перечислены. Далее - другие сущности. Потом определяем связи между ними. Например если многим spec соотвествует один ISNN - то тип связи будет многие к одному. Бывает такое что между двумя сущностями связи многие-ко-многим. Как прямоугольная матрица где по горизонтали одна сущность а по вертикали - другая и на пересечении стоит YES когда связь в наличии. Это тоже можно. Это делается через промежуточную таблицу. Связи бывают рекурсивные (таблица может указывать сама на себя). И в РМ могут быть циклы и петли. Это тоже допускается. Просто в этом случае между сущностями будут несколько вариантов как их джойнить и все варианты верны.

3) После того как Реляционная Модель (РМ) определена - в нее можно загружать данные. Можно грузить через INSERT/UPDATE/MERGE. И если возможностей не хватит то можно брать хранимые процедуры на Postgres. Но обычно мне хватало и SQL. В крайнем случае можно брать языки типа Python, Ruby e.t.c. если например доменная модель ооооочень сложная и надо какие-то делать неочевидные поиски по коллекциям или работать с JSON/XML но у тебя вроде все атомарно и лежит просто в ячейках. Должно хватить SQL.

4) Последняя таблица izdanya - по смыслу является отчетом из основной модели. Я настаиваю именно на таком подходе. Физически - это может быть view или таблица неважно. Главное что она - вторична по отношению к модели.

При высокой нагрузке близкой к 100% пользователь может совершить транзакцию на создание объекта в базе. Сама транзакция может подвиснуть. Пользователь не дожидаясь ответа обновляет страницу и снова создает объект. Получается уже две транзакции в очереди. По итогу когда очередь доходит до выполнения имеем в базе два одинаковых объекта (созданных вплоть до ms) что ломает логику программы.

Очень плохо что вы довели систему до нагрузки 100%. Обычно concurrency работает хорошо когда мы не доводим до такого состояния. Есть даже такой термин thread starvation (голодание потоков) когда потоки никак не могут получить квант времени.

Без кода и лог-файлов тут нечего обсуждать. Я просто могу дать несколько направлений на подумать.

1) CQRS (Command-Query-Separation) - это шаблон разработки при котором команды на изменение данных и запросы на их чтение идут независимо и существуют как-бы в разных временных эпохах. Это дает возможность масштабировать системы довольно сильно. И такие системы обычно лишены блокирок.

2) Idempotency- это два свойства бизнес операций. Идемпотентность например предполагает что если платежная система дважды продублировала ваш платеж (MQ/сетевые replays) за покупку чашки Кофе например то это не означает что с вас банк снимет дважды деньги. На самом деле каждая ваша карточная операция имеет уникальный ID и с точки зрения биллинга будет применение платежа только 1 раз с одним уникальным ID. Второй платеж-дубль будет проигнорирован. Это свойство часто используется в Apache Kafka как один из способов поднять скорость и надежность.

3) Когда ваша база или сервер приложений находтся в состоянии как-бы "агонии" то не стоит пытатся добивать ее повторами операций. А стоит на некоторое время прикрыть канал операций. Или разорвать цепь предохранителя. Как делают в электрике при повышенной нагрузке. Есть такой шаблон Cirquit Breaker. Аварийный размыкатель. Netflix его активно использует.

Вот подумайте.

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

Техническая часть. Очевидно что нужна еще одна таблица. С датой аудита. С реквизитами пользователя который делал бизнес-операцию. И две версии данных. "До" и "после" изменения. Данные можно хранить в денормализованном формате (XML или Json) для простоты схемы.

Тут сложно ответить однозначно. Тут есть какое-то дублирование технологий. С одной стороны - есть некий
умный софт (автор пишет nlp-средство) который сделал разбиение писем на слова. Зачем именно nlp? В чем там была глубокая идея? Разве нельзя это-же разбиение сделать с помощью
- Postgres
- MySQL
- SQlite
как предлагали выше ?

Так было-бы проще. А теперь мы все думаем - зачем так сложно?

Сейчас совсем не понимаю с чего начать, нужно ли сначала спроектировать базу, а потом уже бекендом заняться, или все же вместе с беком все делать?

Из практики я не встречал в жизни такой задачи где-бы проектирование было с нуля и до конца.
Бизнес меняется. Постоянно появляются новые услуги. И под них растет база. Я-бы на твоём месте
не стал-бы упарываться вопросом именно проектирования базы. Я-бы доверился итеративному
процессу наподобие scrum-agile. Делаешь первую версию БД. Показываешь демо. Потом снова
итерации. Я надеюсь с командой alter table ты знаком? Ну и прекрасно. Значить в любую
табличку можешь внести изменения. Табличка это не железо-бетон. Если надо - пределай.

Если ты нашел в интернете нечто и хочешь под него что-то спроектировать в БД - тогда
экспертом по бизнесу являешся ты. И ты должен сам себе задать вопросы. Какие данные
будут лежать? Ключи и атрибуты.? Как они связаны.? Тут появляются связи один-ко-много или много-ко-много.
Это концептуальный уровнь. И на физическом уровне могут появится индексы. Партишены.

Если ты не знаешь какие сущности там будут лежать - то пойди от бизнес-кейсов. Например кейс.
Человек хочет сделать заказ. Или еще другой кейс. Человек пришел оплатить заказ.
Оплатил. Попользовался неделю. Потом ему что-то не подошло и он потребовал возврат.
Из кейсов сразу появляются сущности. Клиент. Заказ. Склад. Платеж. Фидбек. Flow товара по магазинам
и складам. И так далее.

Если начнешь делать - делай по минималке. Лучше сделать меньше но самодостаточно чем поначинать
тысячу сущностей и бросить их.

Если это просто сет документов - то и надо брать документно-ориентированные БД.
MongoDb например или CouchDb.

1:M к "серии", и считать что фильмы, у которых больше 1 серии - это сериалы, тогда как быть с сезонами?

Есть много способов как представлять данные в БД. В схеме Фильм - Сериал - Сезон нет единой правильной модели
как лучше это хранить. Наверное все зависит от users stories тоесть от хотелок пользователя. Например хочет ли пользователь видеть что СРЕДИ сериала вдруг появляется пропуск в сериях или есть пилотная серия (которую надо выделить отдельно). Или например есть серия в котороой нет озвучки. Вот эти все вопросы надо спросить эксперта. В данном случае - тебя поскольку ты придумываешь себе предметную область.

Поэтому сразу совет - придумай ее как можно проще. Пускай это будут просто фильмы. 1 таблица с фильмами. Реализуй ее. Посмотри на нее. Я думаю что уже на этом этапе твой пет-проект может стать бесконечно сложным. Еще не доходя до сериалов.

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