SS
Опа 🌚
Size: a a a
2021 March 10
w
К бизнес логике
VL
currencies(id,title)
tariffs(id,title)
prices(tariff_id,currency_id,price)
transactions(user_id,tariff_id, currency_id,amount,...итд)
что то такое получится наверное
tariffs(id,title)
prices(tariff_id,currency_id,price)
transactions(user_id,tariff_id, currency_id,amount,...итд)
что то такое получится наверное
вот так накидал. вроде уже норм? транзакции потом сделаю
SS
А чего сервисы не в отдельную таблицу?
SS
Разные тарифы ж могут одинаковые сервисы включать ?
VL
Разные тарифы ж могут одинаковые сервисы включать ?
и да и нет. в одном тарифе могут быть 10 модулей, а в другом 20 + 10 смс
SS
А если предположить что дальше еще тарифы добавляться будут?
//Обычно это происходит в режиме "ааа, все, всему хана, еще вчера надо!"
//Обычно это происходит в режиме "ааа, все, всему хана, еще вчера надо!"
SS
Опять же, можно структуру долго доводить до идеальной с точки зрения БД, но надо знать когда притормозить 🌚
VL
А если предположить что дальше еще тарифы добавляться будут?
//Обычно это происходит в режиме "ааа, все, всему хана, еще вчера надо!"
//Обычно это происходит в режиме "ааа, все, всему хана, еще вчера надо!"
конечно будут. создаться запись в tarifs потом проставяться ключи значения в tarif_service и в tarif_price и в tarifs_translations и будет новый тарифный план
VL
с key value можно кучу комбинаций сделать, и задать им всем одну цену в tarif_price
SS
ну для начала можно, просто дальше может быть сложнее, типа "в этом тарифе 20 смс, в этом 50, а в этом еще и 100500 сообщений в телегу"
VL
ну для начала можно, просто дальше может быть сложнее, типа "в этом тарифе 20 смс, в этом 50, а в этом еще и 100500 сообщений в телегу"
ну так будет в tarif_service такие поля tarif_id => 2 key => sms value => 20, tarif_id => 3 key => sms value => 50. или так нельзя?
SS
Можно, но дубли же🌚Поэтому я и веду к тому что услуги в отдельной таблице (ид, название,slug) а в service_tariff - id тарифа, id услуги, количество, типа такого
VL
Можно, но дубли же🌚Поэтому я и веду к тому что услуги в отдельной таблице (ид, название,slug) а в service_tariff - id тарифа, id услуги, количество, типа такого
я думаю что это было бы оправдано если бы нам нужно было название услуги и выводит все это в тексте, а так админ может просто в описание тарифа просто перечислить название услуги и количество. а так если нам не нужно поле name в отдельной таблице services_for_tarifs то наверно в ней и смысла нету?
VL
нам главное в системе понят, может ли юзер создать к примеру больше 5 модулей или нет
SS
Экономия "на спичках")
Мы же не знаем, что будет с проектом через N месяцев)
В целом для начала можно остановиться и на более простом варианте, а по мере роста уже рефакторить
Мы же не знаем, что будет с проектом через N месяцев)
В целом для начала можно остановиться и на более простом варианте, а по мере роста уже рефакторить
SS
Я как то так "сэкономил" одно поле, а через годик понадобилось слепить отчет, и там этого поля оох как не хватало 🌚
"таких костылей не знавала земля"
"таких костылей не знавала земля"
VL
Экономия "на спичках")
Мы же не знаем, что будет с проектом через N месяцев)
В целом для начала можно остановиться и на более простом варианте, а по мере роста уже рефакторить
Мы же не знаем, что будет с проектом через N месяцев)
В целом для начала можно остановиться и на более простом варианте, а по мере роста уже рефакторить
экономия будет на двух таблицы не будет services_for_tarifs и services_for_tarifs_translations для перевода, хотя хз как в будущем будет)
НГ
Кто-нибудь отправлял в телеграмм сообщение из пхп?
НГ
Тип «заказ создан»( новый заказ + данные )