.
Всем привет, можете подсказать что вы используете для миграции postgresql
Size: a a a
2020 July 28
A
Всем привет, можете подсказать что вы используете для миграции postgresql
typeorm
¿
Всем привет, можете подсказать что вы используете для миграции postgresql
knex
И
Всем привет, можете подсказать что вы используете для миграции postgresql
https://github.com/salsita/node-pg-migrate
как-то с таким игрался, выглядит неплохо
как-то с таким игрался, выглядит неплохо
s
const data = await univerModel.find({}, {region: 1}).sort({ region: 1})
console.log(data)
что выдает?
console.log(data)
что выдает?
странно, но ничего
в
тема afterglow?
s
тема afterglow?
это мне?
s
незнаю такого слова
NS
незнаю такого слова
Theme редактора наверное
AB
тема afterglow?
Vscode есть тема One dark.
s
Ребят подскажите пожалуйста, допустим у меня есть у продукта 9 тарифов, подписка 1,2 и 3, также есть каждая версия на 6 мес сразу где 1 мес бесплатно и год где 2 мес бесплатно. Мне надо сделать в бд 9 тарифов или лучше 3 тарифа и просто даты окончания разные всегда делать?
AB
Ребят подскажите пожалуйста, допустим у меня есть у продукта 9 тарифов, подписка 1,2 и 3, также есть каждая версия на 6 мес сразу где 1 мес бесплатно и год где 2 мес бесплатно. Мне надо сделать в бд 9 тарифов или лучше 3 тарифа и просто даты окончания разные всегда делать?
1. 9 тарифов, это откровенно говоря - перебор. Обычно когда "много" тарифов, возникает чувство, что хотят обмануть. Обычно этим пользуются "провайдеры".
Пожалуйста, не надо так,... :D
2. В БД отдельно создается самодостаточная сущность.
Условный пример: Если у тебя 1 тариф, который ты предоставляешь по скидке 1-3-6-12 месяцев, нет смысла создавать 4 тарифа с разным периодом, скидкой. Параметры тарифа не изменяются. "Правильнее" создать 1 тариф и вычислять скидку на лету.
Например, можно создать единую таблицу для видов скидок.
Пожалуйста, не надо так,... :D
2. В БД отдельно создается самодостаточная сущность.
Условный пример: Если у тебя 1 тариф, который ты предоставляешь по скидке 1-3-6-12 месяцев, нет смысла создавать 4 тарифа с разным периодом, скидкой. Параметры тарифа не изменяются. "Правильнее" создать 1 тариф и вычислять скидку на лету.
Например, можно создать единую таблицу для видов скидок.
М
1. 9 тарифов, это откровенно говоря - перебор. Обычно когда "много" тарифов, возникает чувство, что хотят обмануть. Обычно этим пользуются "провайдеры".
Пожалуйста, не надо так,... :D
2. В БД отдельно создается самодостаточная сущность.
Условный пример: Если у тебя 1 тариф, который ты предоставляешь по скидке 1-3-6-12 месяцев, нет смысла создавать 4 тарифа с разным периодом, скидкой. Параметры тарифа не изменяются. "Правильнее" создать 1 тариф и вычислять скидку на лету.
Например, можно создать единую таблицу для видов скидок.
Пожалуйста, не надо так,... :D
2. В БД отдельно создается самодостаточная сущность.
Условный пример: Если у тебя 1 тариф, который ты предоставляешь по скидке 1-3-6-12 месяцев, нет смысла создавать 4 тарифа с разным периодом, скидкой. Параметры тарифа не изменяются. "Правильнее" создать 1 тариф и вычислять скидку на лету.
Например, можно создать единую таблицу для видов скидок.
У многих хостеров так.
в
вместо 9 тарифов уж лучше кастомизатор сделать)
М
Это маркетологам над сказать
М
Но они дают кастомизатор же на выбор? Только он не выгодный
М
Подскажите стоит ли делать на бэкенде API только GET/POST запросами с конкретными методами или всё же делать полностью по стандарту REST используя все http методы? Что будет более верным?