|
|
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Ситуация следующая. Есть поликлиника, где пациент может оплатить лечение несколькими способами. Способ оплаты 1. За наличные 2. Оплачивает государство 3. По договору ДМС (добровольное медицинское страхование) Ограничения 1. Цены в прейскуранте могут периодически меняться. Не на все услуги а на некоторые. 2. Для договоров по ДМС отдельный прейскурант. Там тоже могут цены меняться. Сейчас сделано следующим образом. Для каждого периода и для каждой страховой компании своя dbf с прайсами. Т.е. в программе выставили тип оплаты, и в зависимости от даты и от компании подгружается нужный прайс. Сейчас хочу отказаться от DBF т.к. начальство даёт время на доработку. Мне интересно можно ли сделать следующую таблицу? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 12:38 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Hopkroftможно ли Можно, разрешаю. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 12:41 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Hopkroft, можно и так, только я бы еще добавил конечно Ид-р. Или еще как вариант убрать поле DT_END, добавить поле "актульно" типа бит. Есть плюсы и минусы у обоих вариантов, но во втором случае возможно бытрее получить в запросу актуальную цену. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 12:46 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, Спасибо:) Nashville , авторможно и так, только я бы еще добавил конечно Ид-р. Или еще как вариант убрать поле DT_END, добавить поле "актульно" типа бит. Есть плюсы и минусы у обоих вариантов, но во втором случае возможно бытрее получить в запросу актуальную цену. Какой идентификатор? Если вы за название услуги и код услуги, то это обязательно. Я их опустил, что-бы сконцентрироваться на задаче. Получить актуальную можно запросом. Код компании по умолчанию сделать 0, при этом сами компании нумеровать от 1. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Понятие "актуально" очень относительно. Например придёт пациент и скажет. А дайте мне прейскурант за то число когда мне оказывали услуги и сегодняшнее, я хочу сравнить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 13:10 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Hopkroft, 1. я имел ввиду идентификатор записи в таблице (я понял, что вы за очевидностью его просто опустили) 2. Тут есть два момента. Первый, это быстродействие при получении цены. Оцените, что более всего используется у Вас, последняя цена или историческая, скорее всего первое. Для больших прайсов и нагруженной БД, разница при выполнении приведенного Вами запроса (т.е. фильтр по полю типа DATE и отбор значений NULL) и запроса с фильтром по полю типа bit, может быть для приложений заметна. Второй момент, при использовании пары значений DATE_START и DATE_END Вы должны предусмотреть механизм недопушения пересечения или нестыковки этих пар для одинаковых ИД, что предложенный мною вариант позваляет избежать, хотя минусом данного подхода будет более сложный запрос по выбору "исторических" данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 13:33 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Nashville, По поводу ключевых полей Код: plsql 1. 2. 3. 4. Т.к. одна и та же услуга может поменяться в 1 день у всех компаний и для всех типов оплаты. Например начало года. Почему не хочу вводить поле, актуальная дата. Приходит например, зав. отделением и говорит. С понедельника услуга номер 286 будет стоить не 15 рублей, а 16. Или она вообще будет удалена. И мне придётся каким-то образом в понедельник выставлять поле в 1 что-бы оно появилось/пропало в выборке актуальное. Особенно это касается окончание действия услуги. (Это не фантастика. Например, изготовлением какого-то протеза занималась другая организация. И с понедельника, было решено отказаться от этой услуги т.к. она оказалась не рентабельна.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 13:49 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Nashville, не написал про пересенение... Для его реализации, необходимо его предотвратить в редакторе прейскурантов. Меняем дату актуальности у услуги, и автоматически открываем новую дату актуальности и закрываем старую. Как-то так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 13:59 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Я вижу в обсуждении отметки об актуальности цены только проблему, что мы не знаем когда услуга была прекращена. А что если решить проблему таким образом: Таблица список прайсов (id прайса, тип (хотя лучше наверное способ) оплаты, id услуги, код компании, дата закрытия) Таблица цен (id прайса, дата актуализации прайса, цена по прайсу, признак актуальности) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 14:08 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Hopkroft, не только пересечение но и случай когда может оказаться, что на какую то дату нет цены. Хозяин барин, кукаю схему применять зависит от задач, условий и ограничений. Универсальных решений и подходов нет. И еще, использовать составной праймари ключ или нет, зависит от конкретной СУБД и прочей лабуды, например, быстродействия репликации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 14:09 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Mr.Fontaine, мне ваша схема не показалась простой и очевидной. В предложенном мной варианте дата окончания действия цены, будет следующая дата начала -1 день. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 14:13 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Mr.Fontaine, я хотел одной таблицей обойтись. Т.к. в итоге может быть 5-7 прайсов. Можно конечно создавать отдельные таблицы в базе, но какое-то это извращение. У меня сейчас 8-10 dbf файлов, в каждом где-то 200 записей. Так что одна таблица будет самое то. Хотя, может кто знает эффективнее решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 14:15 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
NashvilleHopkroft, не только пересечение но и случай когда может оказаться, что на какую то дату нет цены. Если нету, значит её убрали из прейскуранта. НО в этом случае, в регистратуре не смогут вбить услугу, после её окончания. Так что проблем при калькуляции, отчётов не возникнет. NashvilleИ еще, использовать составной праймари ключ или нет, зависит от конкретной СУБД и прочей лабуды, например, быстродействия репликации. Репликация, это обычная замена таблицы. Честно сказать, я пока не вижу необходимости у каких-то таблиц, делать внешние ключи на таблицу с прейскурантом. Хотя быть может такая необходимость есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 14:22 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Hopkroft, При таких объемах все равно какую схему использовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 14:25 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
NashvilleHopkroft, 1. я имел ввиду идентификатор записи в таблице (я понял, что вы за очевидностью его просто опустили) 2. Тут есть два момента. Первый, это быстродействие при получении цены. Оцените, что более всего используется у Вас, последняя цена или историческая, скорее всего первое. Для больших прайсов и нагруженной БД, разница при выполнении приведенного Вами запроса (т.е. фильтр по полю типа DATE и отбор значений NULL) и запроса с фильтром по полю типа bit, может быть для приложений заметна. Второй момент, при использовании пары значений DATE_START и DATE_END Вы должны предусмотреть механизм недопушения пересечения или нестыковки этих пар для одинаковых ИД, что предложенный мною вариант позваляет избежать, хотя минусом данного подхода будет более сложный запрос по выбору "исторических" данных. все давно придумано до вас.... гуглим SCD2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 14:26 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
NashvilleHopkroft, При таких объемах все равно какую схему использовать. Ну это понятно что сейчас она простенькая. Но как-бы делаю не на один год. Плюс боялся что могут быть подводные камни или более эффективные решения. Ivan Durak , спасиб, за ссылку. Посмотрел бегло, идея понравилась. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 14:52 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Hopkroft Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. Сделай уж сразу сущность -- прайслист. Даты действия например не у конкретной позиции, а у всего прейскуранта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 17:35 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Mr.FontaineЯ вижу в обсуждении отметки об актуальности цены только проблему, что мы не знаем когда услуга была прекращена. А что если решить проблему таким образом: Таблица список прайсов (id прайса, тип (хотя лучше наверное способ) оплаты, id услуги, код компании, дата закрытия) Таблица цен (id прайса, дата актуализации прайса, цена по прайсу, признак актуальности) Как-то странно видеть признак актуальности услуки в ценах на эту услугу. Цены -- ценами, актуальность -- актуальностью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2013, 17:37 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
MasterZiv, актуальность цены, а не услуги однако. Ибо с временем цена на услугу может изменяться не? P.S. Хотя, собственно говоря, без цитаты моей фразы, конечно правильно сказано ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 13:19 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Mr.Fontaine, Актуальность цены - это актуальность прайс-листа, где эта цена лежит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2013, 20:17 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
MasterZiv, хотите сказать что для каждого изменения нужно новый прайс создавать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 08:22 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
MasterZiv, где Вы увидели прайс-лист? Таблица прайсов - это не прайс-лист вообще. Хотя бы потому что там нет цен. Я видимо некорректно его назвал. В таблице, в которая у меня названа прайсом лежит детализация услуги: указано какая услуга предоставляется какому предприятию по соответствующему виду оплаты. Ну и дата завершения работы с предприятием по данной услуге и данному виду оплаты. Дату начала работы с предприятием по этой услуге опустил, ибо в рассмотрении данного вопроса от неё толку нет, но так конечно можно её иметь. На всём протяжении работы с предприятием по одной услуге цена этой услуги может изменяться, вот история изменения цен и хранится во второй таблице. Соответственно, во второй таблице необходимо иметь отметку, о том, какая цена для предприятия актуальна в настоящее время. Вот по этим данным и можно строить прайс-лист для предприятия на любую дату. А если говорить об актуальности услуги вообще, без указания предприятия и способа оплаты, то это понятно надо предусматривать соответствующее поле в справочнике услуг. Но разговор-то идёт про актуальную цену, потому актуальность услуги в данной теме форума вообще не рассматривается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 09:56 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
HopkroftMr.Fontaine, я хотел одной таблицей обойтись. Т.к. в итоге может быть 5-7 прайсов. Можно конечно создавать отдельные таблицы в базе, но какое-то это извращение. У меня сейчас 8-10 dbf файлов, в каждом где-то 200 записей. Так что одна таблица будет самое то. Хотя, может кто знает эффективнее решение. я не понял зачем Вам делать отдельные таблицы в базе.... По моей схеме пишите в первую таблицу (конечно подразумевая, что существуют отдельные справочники компаний, услуг и способов оплаты, поэтому в данной таблице пишем просто их id): ключ записиуслугакомпанияоплата111121123113412151226131 во второй таблице ключ записи таблицы 1дата актуализацииценапризнак актуальности101.01.201150N112.12.201253Y201.02.201144N201.08.201245N210.12.201248Y301.04.201130N318.12.201235Y При добавлении новой услуги или нового способа оплаты или изменении цены по какому-либо способу оплаты для одной и той же компании просто добавляем строки в эти две таблицы. Других таблиц не требуется создавать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 10:11 |
|
||
|
Таблица с ценами
|
|||
|---|---|---|---|
|
#18+
Hopkroft, по показанным данным можно получить наличие прайса и стоимость услуги1 для компании1 на любую дату, например 07.01.2011 года компания1 могла получить услугу1 только по способу оплаты1 за 50 единиц измерения цены 22.07.2012 компания1 могла получить услуг1 уже по трём способам оплаты: по 50, 44 и 30 единиц соответственно а 01.08.2012 компания1 могла получить услуг1 уже по трём способам оплаты: по 50, 45 и 30 единиц (так как в истории видно, что вторая цена в этот день поменялась) ну и также можно сделать парйс-лист актуальных цен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2013, 10:18 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38351617&tid=1541148]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
153ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 260ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...