ну ладно, спасибо
напишите сахар
ולאד
ולאד
а еще лучше - рассмотрите keyvalue хранилища типо redis
Artem
а еще лучше - рассмотрите keyvalue хранилища типо redis
у меня там жирная матрица с десятком методов будет
Artem
мб все равно придется писать геттер отдельный
Alexander
перевожу репликасет из одного ДЦ в другой. состав сета: праймари, секондари, арбитр. переносил по доке, на горячую (с поочерёдным отключением нод и реконфигом). праймари и секондари перенеслись норм, арбитр не хочет. со старым арбитром связь есть, он определяется, как арбитр. новый никак не хочет определяться, даже если сносить монгу полностью и заново ставить, затем использовать rs.addArb(...). нода, которую хочу сделать новым арбитром, определяется, как OTHER. версия монги 4.2.3
✆
Кто знаком с parse server. Установил. Есть парочка вопросов
✆
Кто знаком с parse server. Установил. Есть парочка вопросов
App ID и мастер кей нужно в parse server какие вставлять,??? Самому придумывать генерировать? Там типа ключей api
Anonymous
Заработок сидя перед компьютером ( от двух до 6 часов в день )
Наши требования
- Компьютер и интернет
- нацеленность на результат
- минимальный опыт работы в Word&Excel
- внимательность
Обучим, расскажем что и как.
Обращайтесь ко мне в личку или вотсап.
Дмитрий
Влад
App ID и мастер кей нужно в parse server какие вставлять,??? Самому придумывать генерировать? Там типа ключей api
да, сам придумай, это твой ключ от приложения будет как бы)
✆
писал проект с исп. парса. что не так? я в чем-то был не прав?
Ты прав, просто это я сервак переношу, подскажи если знаешь что да как
✆
писал проект с исп. парса. что не так? я в чем-то был не прав?
Серваки домашние.
1й сервер чистый где все делалось через консоль, с монго бд и парсе с дашбордом 1 приложения по стандарту.
Переношу на сервер с панель управления. Там майсквэл и postgre sql вместо манго.
✙ Nikita
манго)
Александр
Вместо монго можно же использовать пострескл??
инструменты выбираются под задачу, обычно можно, а задача-то какая?
Влад
задам сначала свой вопрос: пытаюсь сделать декремент поля типа Long:
$inc: {
'account.holdAmount': new Long(-1 * sum),
},
sum - целое число. с инт 32 так работало, а вот при инт64 мне в результате чисто становится огромным, вместо уменьшения. пытался 13100 уменьшить на те же 13100, вместо 0 получаю что-то в духе 42632363427
Влад
Серваки домашние.
1й сервер чистый где все делалось через консоль, с монго бд и парсе с дашбордом 1 приложения по стандарту.
Переношу на сервер с панель управления. Там майсквэл и postgre sql вместо манго.
я, честно говоря, не работал с серверами с панелями управления. всегда настраиваю голый сервак, на котором разве что убунту установлена. а в чем проблема с разницей в бд? там же определяются только схемы, интерфейс унифицирован, а парс потом по этим схемам в постгрес json сохранит (год назад так точно было).
✆
Можно на сервере с postgre sql развернуть mongodb??? Мешать друг другу не будут?
Alexander
Можно на сервере с postgre sql развернуть mongodb??? Мешать друг другу не будут?
они ж на разных портах работают
Влад
Можно на сервере с postgre sql развернуть mongodb??? Мешать друг другу не будут?
сделать такое проблем нет. но на счет "мешать", хз. будут драться за системные ресурсы, наверное. вообще такое не рекомендуют делать (в руководствах), не практиковал
✙ Nikita
подскажите пожалуйста типы задач, в которых вот прям 100% нужно использовать реляционные бд, а никак ту же монгу, а то какой проект не попадеться, постоянно тянет решить его на монгобд, но в тоже время опыт с sql тоже бы не помешал
✆
сделать такое проблем нет. но на счет "мешать", хз. будут драться за системные ресурсы, наверное. вообще такое не рекомендуют делать (в руководствах), не практиковал
Постгре у меня пустой, майсквэл обычно использую
Artem
Я могу использовать другие поля документа в функции default при создании этого объекта?
Александр
подскажите пожалуйста типы задач, в которых вот прям 100% нужно использовать реляционные бд, а никак ту же монгу, а то какой проект не попадеться, постоянно тянет решить его на монгобд, но в тоже время опыт с sql тоже бы не помешал
Раньше я бы сказал что если нужны транзакции. Но сейчас транзакции и в монгу завезли. Поэтому это вопрос скорее удобства. В реляционках удобно делать всякие проверки целостности данных, связи между таблицами, триггеры можно вешать, заворачивать логику в хранимки. Аналитика всякая на SQL проще делается и быстрее работает.
Правда если данных станет очень много, то шардировать придётся руками, будьте к этому готовы.
Александр
В постгресе много разных типов индексов.
✙ Nikita
Спасибо, ну а всякие там финансы, учетные данные (списания всякие), где нужна гарантия целостности данных и верных рассчетов, это все тоже на монгу нормально ложится?
Александр
Разграничение прав, насколько я знаю, в реляционках гибче настраивается.
Александр
Спасибо, ну а всякие там финансы, учетные данные (списания всякие), где нужна гарантия целостности данных и верных рассчетов, это все тоже на монгу нормально ложится?
Говорят что уже да, но я боюсь пробовать)) главное не забыть транзакции использовать.
Александр
Ну и кода получится больше с монгой
✙ Nikita
"триггеры можно вешать, заворачивать логику в хранимки"
вот именно, что я сторонник описывать всю бизнес логику в самом приложении, а не вешать ее на субд, поэтому не могу понять - нужен ли постгрес все таки или нет?))
✙ Nikita
"Аналитика всякая на SQL проще делается и быстрее работает. "
ну вот разве это, там действительно это как -то удобней, в монги хоть и есть фреймворк для агрегаток, но он чет мне "страшнее" показался чем просто select AVG(field) from table в sql
Александр
"триггеры можно вешать, заворачивать логику в хранимки"
вот именно, что я сторонник описывать всю бизнес логику в самом приложении, а не вешать ее на субд, поэтому не могу понять - нужен ли постгрес все таки или нет?))
Это дело вкуса) я бы сказал что бизнес логику надо писать в одном месте, а в приложении или в базе дело вкуса.
yopp
не стоит хранить бизнес-логику в базе, потому что её нормально тогда будет понимать никто примерно
yopp
yopp
дешевле выбрать тот инструмент с которым у вас есть боевой опыт
yopp
если вам ехать, если вам шашечки, то выбирайте что вам больше на солнце блестит :)
Александр
"Аналитика всякая на SQL проще делается и быстрее работает. "
ну вот разве это, там действительно это как -то удобней, в монги хоть и есть фреймворк для агрегаток, но он чет мне "страшнее" показался чем просто select AVG(field) from table в sql
Я как-то переписал функцию на 1500 строк с запросами к монге, мускулю, и склейке этого всего в пхп, на 1 запрос на 300 строк к постгресу, получив ускорение примерно в 200 раз)
yopp
Говорят что уже да, но я боюсь пробовать)) главное не забыть транзакции использовать.
оно и без транзакций работало
yopp
транзакции в 80% случаев не нужны
yopp
«денежные переводы» это очень абстрактная постановка задачи, которая имеет очень абстрактное решение
Александр
не стоит хранить бизнес-логику в базе, потому что её нормально тогда будет понимать никто примерно
Документация важна безусловно
yopp
вам документация не поможет
yopp
у вас будет SPOF в виде человека который фигачит магию внутри базы
yopp
после которого никто ничего там не сделать
yopp
разработчики в этом разбираться не будут, а те кто будет, будут делать это очень долго
yopp
переносить логику в базу это безумно дорогое удовольствие
yopp
и оно оправдано когда стоимость поддержки такого решения окупается выгодой
Маrаt
«денежные переводы» это очень абстрактная постановка задачи, которая имеет очень абстрактное решение
Обычно требуется минимум два документа которые как счета между которыми перевод происходит. Или есть другие варианты такое делать?
yopp
а это 0.1% случаев
yopp
Обычно требуется минимум два документа которые как счета между которыми перевод происходит. Или есть другие варианты такое делать?
вы сейча описываете решение, а не проблему
yopp
а решений очень много, но они зависят от того, как данные используются
yopp
рисовать ограничения необходимо по бизнес-требованиям, причём не по абстрактному представлению, а по реальным кейсам
yopp
там где не нужно реальное время (а это 97% случаев), обычный клиринг-брокер который жуёт раз в N секунд очередь операций дубовее и надёжнее чем попытка сделать это через транзакции
yopp
потому что у вас сразу отпадают вообще все проблемы связанные с обеспечением целостности на уровне операции в базе
yopp
а выбрать за период и прожевать это два запроса
yopp
и никаких вам там конфликтов, ретраев, проблем с видимостью и прочих совершенно ненужных проблем
yopp
у клиринга есть гигантское количество приемуществ, первое это индемпотентность, более того, при минимальном вложении времени вы ещё и append only лог операций получаете
yopp
второе это линейность
yopp
третье это изоляция клиринговой логики в одном месте — брокере
yopp
ну и ещё раз: дубовость. и на базе этой дубовости можно делать очень много разных вещей, которые с транзакциями делать очень сложно. например сложные multy-party переводы. Для всяких маркетплейсов, где один приход распиливается на множество счетов
yopp
если присмотреться к флоу оплат, с которым вы встречаетесь каждый день, там очень часто нет никакого реалтайма :)
yopp
плюс ещё конечно линеаризация операций
yopp
тоже не требует транзакций
yopp
но это всё ещё вариант брокера
Маrаt
Где можно про этих брокеров и клиринг прочитать? Немогу в гугле найти
yopp
клиринг это финансвовый термин, означающий момент когда транзакции реально проводятся
yopp
брокер тож финансовый термин, это что-то что эти самые транзакции осуществляет
yopp
с точки зрения кода, это просто какой-то переодический процесс, который выбирает из базы накопившиеся транзакции и делает по ним проводки
yopp
или например это очередь, в которую складываются тразакции и consumer из этой очереди, который в линейном порядке эти транзакции обрабатывает