В мире 1С нормой считается передача данных через xlsx, лежащие в расшаренной папке. Каждый реализует RPC в меру своей испорченности.

А ТС - жирный тролль, ждём вбросов на тему «как правильно выйти из рекурсии через переполнение стека» и «как записать свои числа в /dev/random».

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

Какая к черту терминология, ты предлагал базу, потом соскочил на сервис, теперь ты просто рассказываешь что ты подразумеваешь не то что я думаю, но не говоришь что ты там подразумеваешь, просто признай что ты ерунды написал, а теперь не знаешь как отбрехаться. Никакие базы и сервисы не нужны это колхоз уровня 1C про который ты можешь почитать выше, но там то понятно дебилы для дебилов пишут, а ты еще можешь вырваться из потоков грязи на размытой сельской дороге.

Я привёл тебе определение базы данных, но ты истерить начал. Теперь пишешь про «соскочить», «дебилы для дебилов пишут» и прочее. Ну какое здесь обсуждение. О чём ты.

ТС - жирный тролль

Это просто на фоне «официальной точки зрения»(доказать которую тут никто не смог и не сможет). Но вроде бы ты верно понял скрытый смысл, nice.

Бери нормальный C++ клиент к БД, например, к Постгресу и юзай.

Берешь и включаешь воображение. Если данные потеряются, то будет вот это и вот это. Делаешь софт, который может это выдержать.

В Вики написано что база антипаттерн в случае когда что-то другое лучше. То есть по определению.

Если данные потеряются, то будет вот это и вот это. Делаешь софт, который может это выдержать

... путём хранения этих данных(или их «исходников»)(или пользователь по второму разу вводит). Я об этом и говорю.

В Вики написано что база антипаттерн в случае когда что-то другое лучше

Да, действительно, невнимательно прочёл. В такой постановке ok.

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

Никто и не говорил....

Думаю ТС очередная реинкарнация кого-то из местных поехавших

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

В кафке нет гарантированной доставки. В кафке есть «скорее всего доставим, обычно проблем не возникает», то есть, асинхронная запись на диск — это неизбежное свойство распределенных ориентированных на производительность систем, поскольку ACID небесплатен. Меня это не удивляет — меня удивляет, что некоторые люди умудряются здесь видеть ACID, хотя его там даже близко нет, даже если кафка стоит на единственной машине.

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

SQLite как готовое безгеморное и безсерверное решение чем не устраивает?

А я и не про кафку, а про AMQP/JMS брокеры. Там на худой конец есть и персистенс в jdbc.

А я и не про кафку, а про AMQP/JMS брокеры. Там на худой конец есть и персистенс в jdbc

Да в них во всех есть опциональное постоянное хранилище. Я вообще не понимаю, зачем их столько наплодили клонов. Да, у них есть разные детали реализации, разные особенности масштабирования, но в целом это плюс-минус одно и то же.

Вот вы отправили в сокет подключения к бд на вставку записи данных и не получили позитивный ответ. Данные вставлены или нет? Если не вставлены, то что делать будете?

Эти данные пришли откуда-то. И пока сохранения не произошло, просто не шлём позитивный ответ отправителю(он должен эти данные хранить на случай неудачи). А когда сохранили - можно уже более сложую обработку делать. Возможно, конечно, не слать ответ до окончания обработки, но это приемлемо только при тривиальной обработке данных, занимающей малое время.

Насчёт вики я ошибся, да. Проблема в том, что не один я такую ошибку совершил. Так что говорят, и ещё как.

Думаю

Ну это же ложь, все мы об этом знаем.

ИПЦ через базу

А как с базой работать будешь? Неужели через ipc?

Чтобы сделать ipc нужен ipc с базой. Рекурсия, однако.

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

Скулайт последние лет 10-15 активно вкорячивают в различный десктопный софт, но в большинстве случаев он там оправдан, для чего он оправдан в ipc кроме лени или не умения писать ipc - не ясно.

Лжешь тут только ты, в первую очередь себе.

Молодец мальчик, теперь реализуй и не морочь голову дядям.

Что ж ты разлогинился-то? Лол

Чёт анон часто рвётся в последнее время. С чего бы это?

А с чего бы межпроцессное взаимодействие утилизирующее минимум 3 ресурса и без специализированных интерфейсов было бы лучше, чем альтернативы эти ресурсы экономящие да ещё и с более подходящим интерфейсом?

Лишняя работа по изобретению протокола который будет построен на примитивах которые не позволят реализовать его эффективно by-design, лишние ресурсы, удивляет пользователя, плохо масштабируется (CAP теорема какбэ намекает, а целостность данных тут скорее то, что хотелось бы выкинуть).

Крч в шаражкиной конторке на коленке - можно всё, особенно в условиях «надо вчера», но по факту при условии адекватной утилизации ресурсов это решение будет всегда проигрывать специализированным альтернативам, возможно даже на порядки попугаев.

О! Ещё база данных это дополнительная точка отказа будет в целом ряде случаев. Например, если использовать её только для ipc (про что в приведённой тобой брошюрке с вики скорее всего и речь).

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

было бы лучше, чем альтернативы эти ресурсы экономящие

Показывай эти альтернативы. Там выше было про редис и брокеры, но они в таких режимах от бд не отличаются вообще никак. Хотя

а целостность данных тут скорее то, что хотелось бы выкинуть

зачем тебе тогда вообще ipc - просто потеряй данные сразу после приёма(раз уж так хочется выкинуть).

Ты опять ничего не ответил. Показывай альтернативы. Побежал

Кстати, я понял, что не так с анонами стало - каникулы же, лол.

Как ответ на твой философский посыл, можно ещё спросить в ответ, а почему ipc на основе rfc1149 или комментариев к банковским транзакциям это не антипаттерн, ведь можно, и то и то в избытке, в первом случае даже практически бесплатно?

Блин, царь чё логиниться начал…

Рак мозга говорят лечат медицинской марихуаной, но - только один раз.

Ведь других надёжных способов организации взаимодействия не существует

grpc, thrift

царь

Чини детектор. И да, я всё ещё жду обещанных легковесных альтернатив.

надёжных

grpc

https://ru.wikipedia.org/wiki/Надёжность

порвался увы ты еще на первой странице когда вместо ответов на вполне логичные доводы просто начал кивать на твоих собеседников и писать чушь типа той что пишешь сейчас, пытаясь очернить собеседников, а не оправдать свою точку зрения, ты по факту отвечай за свою теорию с базой данных которая стала сервисом. Это даже не ipc а обычная клиент-серверная возня. Ты не привел ни одного довода в пользу этой ерунды, кроме того, что тебе так проще потому что ты нулевый и по другому осилить не можешь.

Было время, когда стали модны хранимые процедуры в БД, так чуваки на них целые приложения пилили, с событиями на триггерах.

мы в нулевых фор фан писали текстовую рпг чисто на триггерах и хранимках в оракле (правда не доделали).

Уж точно надёжнее db :D

А уж об удобстве и говорить нечего.

Гипотеза

Пользователи хотят консистентности. Консистентные данные сложно масштабируются. Потому грузить БД чем-то кроме хранения == залезать бутылке в горло. Пока всё влазит в одну машину – проблемы нет. А потом нужно всё переписывать. Последнее отличает хорошую архитектуру от плохой. Следовательно, subj.

Базы данных очень разные, но «в принципе» антипаттерн складывается из двух частей:

1. Больших затрат на персистентность и/или долговечность данных проходящих через Database-as-IPC.
2. Затруднений из-за отсутствия или неуклюжести API базы данных для организации работы для прослушивания запросов и получения ответов.

Поэтому для «традиционных» SQL-ных БД это (примерно) антипаттерн, а (например) для Tarantool - один из штатных режимов работы (с массой возможностей и крутилок).

Уж точно надёжнее db :D

Забыл в оп написать, что тред не для любителей альтернативной терминологии. Но да ладно.

Мне кажется, что ты под бд только рсубд подразумеваешь, но это не так. А хранить придётся в любом случае.

Поэтому для «традиционных» SQL-ных БД это (примерно) антипаттерн, а (например) для Tarantool - один из штатных режимов работы (с массой возможностей и крутилок).

В такой формулировке(с небольшими оговорками) тоже ok.

только рсубд подразумеваешь

Я под БД подразумеваю места, которые нельзя откатить на позавчерашний бэкап.

хранить придётся в любом случае

Это всегда не так – любая система должна относительно спокойно переживать потерю данных(восстанавливая из левых источников, или забивая). Т.о. вообще «не нужно». Но об этом лучше не думать – спокойнее спится.

восстанавливая из левых источников

Странная формулировка. Хранить не нужно, но есть левый источник, который хранит данные. Это новая философия разработки - всё, что можно, объявить «левым»?

или забивая

Как я уже писал, можно забить сразу, прямо на организацию ипц. Ибо зачем оно нужно, если на передаваемые данные можно забить.

grpc, thrift Хахахахаха :-) Это вообще не ясно для чего нужно :-)

для чего он оправдан в ipc кроме лени или не умения писать ipc

Это же 90% рынка рабочей силы.

Хороший такой ipc в виде сервера (базы данных), который (сервер) по определению умеет только принимать запросы от клиентов. Почти всю логику ipc (обмен сообщениями, синхронизацию, вызов процедур, что-там-еще) придется писать на стороне клиента через механизм запросов. Хороший, качественный «шаблон».

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

Странная формулировка

Переформулирововыю. Если какие-то данные достаточно важны, следует исходить из предположения о вероятной поломке БД. И если это предусмотреть «хорошо», хранение в БД уже становится не обязательным. Ибо у тебя есть запасной вариант.

А если этого не сделать хорошо – при сюрпризах ты даже не узнаешь, что именно потеярлось. Там, где это приемлемо, мысли о важности таких данных есть просто почёсывание ЧСВ.

А если они не достаточно важны, чтобы об этом задуматься –

забить сразу, прямо на организацию

или её часть может быть целесообразнее, в этом нет ничего нербычного, стоимость данных очень разная, и вероятно бывает отрцательной.

Гвозди можно микроскопом забивать. Ну жа ладно.