Здравствуйте, IncremenTop, Вы писали:

IT>Здравствуйте, gandjustas, Вы писали:

G>>ACID это здравый смысл, он нужен всегда.
IT>Нет, в многих нагруженных систем от него ушли в сторону саги.
Это проблема систем. С точки зрения пользователя и бизнеса большинство транзакций — ACID, дал денег — получил товар, — получил деньги — оказал услугу.
Часто вы покупали что-то в магазине, а вам вместо товара говорили "данные получены, когда-нибудь вы получите товар, наверное".

IT>Потому что почти всегда нужна асинхронность на уровне процессов.
Асинхронность и ACID не связаны.

G>>Но это часть оптимизации, предварительной оптимизацией лучше не заниматься.
IT>Аcid — это такое же перепроектирование, когда есть две таблички, а люди лепят РБД.
Когда ты говоришь о "табличках" ты уже пользуешься реляционной моделью данных. Почему бы для нее не использовать РСУБД?

G>>А чего неудобного в хранении таких данных в БД?
IT>Опустим то, что это надо проектировать, а не из коробки использовать.
IT>Но уж то, что нет инструментов из коробки, которые умеют в анализ и, например, свертку.
Тут нужна конкретика.
Вот есть данные с вот такой схемой, и вот такие запросы.
Нереляционная БД Х делает вот такие запросы, а РСУБД — не может так делать, потому что У.
А просто сравнивать фичи бесполезно. РСУБД по общему набору фич и покрываемых сценариев порвет любую релеляционную БД.

IT>При этом по скорости, если уж лепить из непрофильного, например, из касандры ТСДБ, то она будет на порядки быстрее.
G>>"Виноваты" ученые, которые доказали что реляционная модель данных позволяет решать те же задачи, что и любые другие модели. Поэтом реляционная субд — универсальная.
IT>Прошло почти полсотни лет.
Теореме пифагора уже тысячи лет, это не делает её менее верной.
В мире математики рулит доказательство, а не частное мнение. Неуниверсальность РСУБД надо доказать. Для этого надо описать класс данных (схемы) и операции над ними, которые запросами в РСУБД сделать невозможно или крайне сложно и неэффективно.