|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
18.11.2021, 23:11
|
|||
|---|---|---|---|
|
|||
Проектирование базы предложений |
|||
|
#18+
Приветствую! Столкнулся с проблемой проектирования базы и приложения. Есть таблица с ценами: id create_date shop_id product_id price Таблица показывает актуальные цены на конкретные продукты в конкретном магазине. Подразумевается, что цена в течение времени может изменяться. В этом случае в таблицу добавляется новая запись с новым значением create_date. Приложение вытаскивает актуальные (действующие на конкретную дату) и предлагает их купить или заказать. Вопрос. Как лучше спроектировать базу, чтобы хранить информацию об истории изменения цен в магазине по продукту, но при этом указать приложению, что данный продукт в конкретном магазине на дату запроса больше не продается? Я думал сделать это простым занулением цены, что будет означать, что товар снят с продажи. Но иногда товар может продаваться бесплатно. Как лучше организовать? Как это делают интернет-магазины? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.11.2021, 23:36
|
|||
|---|---|---|---|
|
|||
Проектирование базы предложений |
|||
|
#18+
Добавь к create_date ещё и delete_date. Заодно и запросы цены на определённую дату упростятся, поскольку достаточно будет BETWEEN. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.11.2021, 01:48
|
|||
|---|---|---|---|
|
|||
Проектирование базы предложений |
|||
|
#18+
Вы имеете ввиду сделать поля "Дата начала" и "Дата окончания"? Тогда возникает новая проблема: нужно контролировать пересечения периодов при попытке добавить новую запись... Но вариант наверное неплохой... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.11.2021, 02:18
|
|||
|---|---|---|---|
|
|||
Проектирование базы предложений |
|||
|
#18+
ElfixТогда возникает новая проблема: нужно контролировать пересечения периодов при попытке добавить новую запись... Можно, но не нужно (ибо напряжно для СУБД). Это задача приложения - корректно завершить один период и начать новый. В некоторых случаях пользователи могут даже найти применение для двух одновременно действующих цен. Их фантазия иногда неописуема. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.11.2021, 10:26
|
|||
|---|---|---|---|
Проектирование базы предложений |
|||
|
#18+
И добавьте поле "тип цены", т.к. в общем случае цен может быть несколько (оптовые, ВИП, акционные и пр.). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.11.2021, 13:20
|
|||
|---|---|---|---|
|
|||
Проектирование базы предложений |
|||
|
#18+
Elfix, Если правильно понял: https://habr.com/ru/post/101544/ https://en.wikipedia.org/wiki/Temporal_database#Bitemporal_Relations ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.11.2021, 16:53
|
|||
|---|---|---|---|
Проектирование базы предложений |
|||
|
#18+
ElfixКак лучше спроектировать базу, чтобы хранить информацию об истории изменения цен в магазине по продукту, но при этом указать приложению, что данный продукт в конкретном магазине на дату запроса больше не продается?Не смешивать сущности цены и количества (признак отсутствия). Ибо экономия копеечная, а гемор реальный (для всех). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.11.2021, 00:05
|
|||
|---|---|---|---|
|
|||
Проектирование базы предложений |
|||
|
#18+
Elfix, Если "отсутствие цены" и "цена = 0" это разные понятия, то вполне можно для отсутствия цены использовать значение NULL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.11.2021, 13:04
|
|||
|---|---|---|---|
Проектирование базы предложений |
|||
|
#18+
Elfix Я думал сделать это простым занулением цены, что будет означать, что товар снят с продажи. Но иногда товар может продаваться бесплатно. Как лучше организовать? Как это делают интернет-магазины? Самый простой и быстрый способ- логическое поле (продается/не продается, по умолчанию продается) В САМОМ КЛАССИФИКАТОРЕ ТОВАРА а не в таблице цен... Функционал можно расширить, используя вместо логики целое (0 - не продается, 1- продается, 2- ожидается в ближайшее время, 3- только под заказ, ...) Плюсы: - самый тупой менеджер без всякого анализа может найти продукт и установить нужное значение. - не искажаются цено-временные параметры интервалов (не нужно ничего занулять) Хотя и сомнительна постановка такого вопроса, но всё же не исключена... Elfix но при этом указать приложению, что данный продукт в конкретном магазине на дату запроса больше не продается? то можно признак (продается/не продается) поместить и в таблицу с ценами, тогда это будет хотя бы осмысленно, например с 01.10.21 по 21.10.21 признак 2 (ожидается... ещё едет в магазин) Вообще-то за прошлые периоды, узнать о том, что товар не продавался можно и по отчетам о продаже и по остаткам на дату... Наличие расширенного признака в ценах делает анализ более функциональным (сроки доставки например) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.11.2021, 17:20
|
|||
|---|---|---|---|
|
|||
Проектирование базы предложений |
|||
|
#18+
vmag, В самом классификаторе нельзя, так как тогда придется в связанной с ним таблице хранить информацию в каких именно магазинах продается, а в каких нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.11.2021, 16:59
|
|||
|---|---|---|---|
Проектирование базы предложений |
|||
|
#18+
Elfix Есть таблица с ценами: Я бы задумался, зачем в ней поле id. Смысла у него, в общем-то, нет. Elfix Вопрос. Как лучше спроектировать базу, чтобы хранить информацию об истории изменения цен в магазине по продукту Для этого нужно добавить к записи пару полей date_from / date_to - цена действует с такого-то момента по такой-то. Соответственно, если на данный момент для данного магазина цены нет - он не может продавать этот товар. Elfix Я думал сделать это простым занулением цены Это плохая практика. Она была вынужденной в шестидесятых-семидесятых годах прошлого века, когда вопрос экономии ресурсов стоял неизмеримо острее, чем сейчас. В 21-м веке баланс изменился, и простая-ясная структура данных, порождающая надёжный безошибочный код, стоит куда дороже, чем экономия пары байтов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&tablet=1&tid=1539770]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
| others: | 230ms |
| total: | 366ms |
| 0 / 0 |
