|
|
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Помогите, пожалуйста, с реализацией триггеров на sql Имеется БД покупки билетов на ж/д поезда, одна из таблиц БД "Билеты" с полями: № билета (ключевое) Маршрут (по которому идет поезд) № поезда № вагона № места Пассажир Место покупки билета Место посадки на поезд Дата посадки Время посадки Дата высадки Место высадки Расстояние до конца маршрута Цена Необходимо написать программы для: 1.Триггера, не позволяющего продавать билет на какое-либо место, если другой пассажир уже занял это место и интервалы пути перекрываются. 2.Триггера, автоматически вычисляющего стоимость билета в момент продажи, и добавляющий эту информацию в таблицу «Билеты». (расчет цены по условию [Расстояние до конца маршрута]*2) Заранее большое спасибо за помощь! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 14:15 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
makhrov90, БД озвучьте - у каждой из них есть особенности при написании триггеров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 14:36 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
DarkMaster, Создать базу данных для информационной системы железной дороги (поезда дальнего следования). Основная задача системы — предоставление справочной информации о расписании движения поездов и продажа билетов. Для каждого поезда в системе хранится номер поезда, дата отправления и прибытия, станции, через которые он проезжает (с указанием времени прибытия и отправления для каждой станции) и вагоны, из которых он состоит. Вагоны могут быть различных типов, для каждого типа вагона известны количество мест и коэффициент стоимости билета. Для каждого перемещения между двумя станциями определена стоимость, и цена билета определяется как суммарная стоимость для всех промежуточных остановок, помноженная на коэффициент стоимости для данного типа вагона. На одно место может быть продано более одного билета, если предыдущий пассажир должен выйти к моменту посадки следующего. Для каждого пассажира в момент продажи билета в базу данных заносятся ФИО и номер паспорта. Поскольку система предназначена только для продажи билетов, не требуется хранить информацию о физических вагонах, из которых составлен поезд, достаточно знать, к примеру, что первый вагон в таком-то поезде — купейный, второй — плацкартный, и т.д.. База данных должна содержать следующие ограничения целостности: 1.Между временем прибытия поезда на станцию и временем отправления должен быть интервал не менее 3-х минут. 2.Билет может быть продан не ранее чем за 30 дней. 3.Поезд не может состоять более чем из 20 вагонов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 14:39 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
makhrov90, Для вас тогда лучше в соседний форум "Работа". Ну ладно, попробуем еще раз по буквам - какую СУБД вы намерены использовать? Mssql, Firebird,Postgres,Oracle? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 14:44 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
DarkMaster, вообще, изначально в задании сказано сделать базу в MS Access, а потом каким-то образом еще и триггеры написать.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 14:48 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
DarkMaster, просто, как я понимаю, в первом случае триггер при покупке билета должен поверять совпадение № поезда, вагона, места и даты отправления (как минимум) и если такое совпадение найдено, то должен выдавать ошибку, гласящую, что место занято, а если совпадения нет, то все ок, и билет оформляется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 14:59 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
makhrov90, Логика в этом есть. Теперь тебе осталось придумать,как прикрутить триггер в Акцесс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 15:04 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
DarkMaster, а если без "прикрутки" (например, если бы это была другая СУБД, где не требуется особых изощрений для работы с триггерами)? Просто еще не совсем понятно мне, как сам триггер писать, какие там команды будуд и проч. А по второму триггеру даже идеи нет, как осуществить( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 15:12 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
makhrov90например, если бы это была другая СУБД, где не требуется особых изощрений для работы с триггерами В нормальных СУБД ответ будет сразу "обломись", поскольку контроль взаимосвязи между разными записями триггерами возможен только в монопольном режиме работы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 15:25 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, как-то же это все равно можно запрограммировать, в смысле существует же код для этого триггера ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 15:32 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
makhrov90как-то же это все равно можно запрограммировать, в смысле существует же код для этого триггера Нельзя. Не существует. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 15:34 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakovmakhrov90как-то же это все равно можно запрограммировать, в смысле существует же код для этого триггера Нельзя. Не существует. exclude constraint в postgresql -- т.е. , вероятно, встроенный constraint trigger поверх спец индекса решает задачу пересечения интервалов разных записей. как расширение случая unique (который даже не триггер а unique индекс itself) т.ч. как--то вы мимо тазика. (т.е. , для самопала, кроме лока "for update" нужен механизм логического лока для вновь прибывающих диапазонов -- для очереди. и делов. кончено же в жаренном петухе, не знающем рид коммитеда, но только снапшоты, об очередях на ресурс сложно даже подумать) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 18:06 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
makhrov90, Слово ТРИГГЕР тут многих дезорганизовало. Так как ТРИГГЕР - нечто, работающее автоматически при любом изменении данных. Так как вы сами будете проводить процедуру бронирования билета, то тут по идее никаких триггеров и не нужно. Давайте сначала перефорулируем задачу - по запросу пользователя оформить ему билет, который не конфликтует с уже имеющимися. Если выполнять именно эту задачу, то и никаких триггеров не нужно. Можно даже ужесточить - оформить билет наиболее выгодным для ЖД способом (так, если пасс. А едет из Самары в Рузаевку, а пасс. Б из Рязани в Москву - то лучше выписать им билеты на одно и то же место). А вот триггером можно назвать пост-проверку : после попытки оформления билета проверяется текущее состояние базы на конфликты с только что выписанным билетом (это необходимо, так как пока мы ПРОВЕРЯЛИ билет перед записью, кто -то уже мог именно этот билет (или конфликтующий с ним) забронировать. Алгоритм такой: 1) Пользователь вводит номер поезда, дату и класс, место отправления и назначения 2) Система подбирает ему билет, желательно оптимальны образом 3) Билет физически добавляется в систему с флагом - неподтверждённый 4) Запускается (вызывается процедурой выписки билета, а не автоматически как ТРИГГЕР) наш ТРИГГЕР, проверяющий не конфликтует ли наш новый билет с другими УЖЕ ПОДТВЕРЖДЁННЫМИ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 20:17 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
Victor CookinА вот триггером можно назвать пост-проверку : после попытки оформления билета проверяется текущее состояние базы на конфликты с только что выписанным билетом (это необходимо, так как пока мы ПРОВЕРЯЛИ билет перед записью, кто -то уже мог именно этот билет (или конфликтующий с ним) забронировать. Ну так этот кто-то мог забронировать билет и уже после того, как стартовала наша транзакция в которой и работает триггер. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 20:27 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, Dimitry Sibiryakov, Забудьте про триггеры и транзакции. У нас есть поле "Подтверждён" в таблице билетов. Когда мы подбираем кандидата в биелты - смотрим, чтобы не было конфликтов с подтверждёнными билетами. Допустим, подобрали. Записали его в базу без флага "Подтверждён". Запускаем "ТРИГГЕР". Нет конфликтов - ставим флаг "Подтверждён". Для очистки совести можно ещё запустить триггер и при наличии конфликта (вероятность чего мала) флаг "Подтверждён" снять ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 20:59 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
Victor CookinЗабудьте про триггеры и транзакции. Между нами говоря, транзакции как раз призваны решать эту проблему. Victor Cookin Допустим, подобрали. Записали его в базу без флага "Подтверждён". Запускаем "ТРИГГЕР". Нет конфликтов - ставим флаг "Подтверждён". Для очистки совести можно ещё запустить триггер и при наличии конфликта (вероятность чего мала) флаг "Подтверждён" снять Эта последовательность может привести к тому, что оба "конфликтующих" билета будут сняты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 21:14 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин Между нами говоря, транзакции как раз призваны решать эту проблему. Только если блокировать ВСЮ таблицу на запись в определённые моменты - а это не есть хорошо. Кот МатроскинЭта последовательность может привести к тому, что оба "конфликтующих" билета будут сняты. Не спорю. Но это лучше дупликатов. Кроме того, все такие "отвергнутые" билеты можно поставить в очередь и попытаться их удовлетворять уже в синхронном порядке PS Кстати, в Аксессе вроде бы уже появились триггеры ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 21:35 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
Victor CookinКот Матроскин Между нами говоря, транзакции как раз призваны решать эту проблему. Только если блокировать ВСЮ таблицу на запись в определённые моменты - а это не есть хорошо. В общем-то нет - нужны блокировки диапазонов ключей. Например, в описываемом случае достаточно блокировки записей, относящихся к конкретному маршруту конкретного поезда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 21:45 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин В общем-то нет - нужны блокировки диапазонов ключей. Например, в описываемом случае достаточно блокировки записей, относящихся к конкретному маршруту конкретного поезда. Вы правы, так тоже можно. И колонка "Подтверждён" в таблице билетов тогда не нужна. Но не думаю, что Аксесс может это делать. А самое главное - это всё равно не отменяет проверку билета ПОСЛЕ записи - и его возможный откат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 22:16 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
makhrov90... Необходимо написать программы для: 1.Триггера, не позволяющего продавать билет на какое-либо место, если другой пассажир уже занял это место и интервалы пути перекрываются. 2.Триггера, автоматически вычисляющего стоимость билета в момент продажи, и добавляющий эту информацию в таблицу «Билеты». (расчет цены по условию [Расстояние до конца маршрута]*2) Заранее большое спасибо за помощь! Если ввести сущность "участок пути", то первую задачу можно обеспечить, используя уникальные индексы. Билет продается на совокупность участков пути. Т.е., при продаже для каждого участка пути в эту сущность добавляются записи, связанные с данными билетом. Если кто-то попытается перекрыть - получит кейвиолейшн, ибо (в FireBird, по крайней мере) индексы работают вне контекста транзакций. А второй триггер - ты сам написал: [Расстояние до конца маршрута]*2. Заносится в нужное поле в случае успешного добавления записей в участки пути. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2016, 22:37 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
Мне вот интересно - на rzd.ru кто нибудь билеты заказывал? С электронным билетом ездил? Там если пройтись от заказа, до оплаты и вывода на принтер билета можно прочувствовать как всё это происходит (задумка интересная у них)... Ну все эти оптимизации по станциям там скорее всего есть, но преподу я думаю ему не нужны, пусть ТС хоть бронь да продажу сделает - уже медаль будет А в РЖД примерно так (кто не верит, может проверить): - система там не подбирает билет, а по запросу день, откуда, куда предлагает сразу все поезда на которых ты можешь уехать с полнейшей информацией (Вокзалы отправления/прибытия, номер поезда, время отпр. / время прибытия, часов в пути, какие типы выгонов в составе и количество свободных мест в них, все цены на все билеты) То-есть один взгляд и ты у же знаешь на каком паровозе ты едешь (по деньгам, по часам в пути, и на какой лавке) - Тыкаем в поезд, тут уже по вагонам: сколько нижних сколько верхних свободно, тыкаем в схему вагона и выбираем незаштрихованный квадратик нижнее или верхнее (видно скока до туалета осталось) Всё - ткнули значит забронировали, уже на соседнем компе место будет занято, а если успел ткнуть но не первым, то придет комментарий типа - уже занято, попробуйте другое место и меньше жуйте сопли... Ну с этим думаю проблем не будет ни у кого (поставить галку занято (МЕСТО В ПОЕЗДЕ а не билет)) - И вот тут начинается самое интересное - у юзера есть минут 20-30 на то, чтобы оплатить билет картой или ещё как, после этого бронь с места снимается и оно опять свободно, ну а если оплатил, то место занято или до упора или до возврата и ставится рядом галка - продано - Последний пункт (скажу по секрету) реализуется так: галка занято на место при бронировании ставится вместе с датой и временем бронирования. Независимая надстройка над БД примерно раз в пару-тройку минут находит все галки брони без галок продано со временем брони пол часа назад и убирает их нафик (галки) вместе со временем (так снимается неоплаченная бронь иначе агентства забьют бронью все вагоны в первые же сутки) - если это курсовая или диплом - то это Ж... Естессно, для брони без триггеров можно и обойтись (у препода можно выехать и на галочке), а вот для снятия брони... ну в общем я высказал мысли - мож чем и помог... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2016, 00:42 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
vmagВсё - ткнули значит забронировали, уже на соседнем компе место будет занято Оно будет занято только между заданными станциями или на весь маршрут данного поезда? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2016, 12:04 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovОно будет занято только между заданными станциями или на весь маршрут данного поезда? в идеале должно быть не навесь маршрут vmagНу все эти оптимизации по станциям там скорее всего есть, на практике не встречал ни разу, чтоб кто-то вышел в середине и новенький подсел - обычно если кто вышел - то дальше едешь сам (если проводница левака не подкинет), соответственно если кто-то купил билет на московский поезд в твоем купе от ростова на юга, то до ростова как правило едешь один... езжу регулярно, билеты беру заранее - на сайте можно отслеживать сколько к тебе уже приклеилось попутчиков, если за 2 часа до отплытия никого нет - повезло едешь в СВ по цене Купе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2016, 14:35 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovvmagВсё - ткнули значит забронировали, уже на соседнем компе место будет занято Оно будет занято только между заданными станциями или на весь маршрут данного поезда? По логике алгоритма, мы на первом шаге выбрали точки посадки-высадки (от Самары до Рузаевки, к примеру, как тут писали уже),в этот момент мы не знаем какой поезд будет выбран - Самара-Рузаевка или Владивосток-Москва, потому кажется мне, что в дальнейшем используется исключительно эти две точки, к которым уже подбирается поезд и после подбора поезда формируется маршрут на который покупается билет (не смотрел карту, но уверен, что от Самары до рузаевки можно доехать несколькими способами, потому марщрут становится известен только после выбора поезда). и честно говоря не очень понимаю зачем занимать место в поезде Владивосток-Москва на весь маршрут... Это просто финансово невыгодно. Нахрена тогда цены разные? Сидя за компьютером во Владивостоке купить билет от Самары до Рузаевки и можно ехать относительно спокойно от Владивостока до Москвы, ведь заранее известно, что место занято и ни на какой станции никто на него билета уже не купит. Тут главное во Владивостоке в вагон пройти не показывая свой самарский билет. Но эта задача безусловно решаема, ибо для её решения не надо использовать компьютерные программы и разнообразные БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2016, 07:18 |
|
||
|
Триггеры к БД на sql
|
|||
|---|---|---|---|
|
#18+
makhrov90DarkMaster, просто, как я понимаю, в первом случае триггер при покупке билета должен поверять совпадение № поезда, вагона, места и даты отправления (как минимум) и если такое совпадение найдено, то должен выдавать ошибку, гласящую, что место занято, а если совпадения нет, то все ок, и билет оформляется а где в Вашем алгоритме триггера условие "интервалы пути перекрываются"? Оно имеется в исходном тексте задания, а в алгоритме куда-то пропало P.S. Вообще лучше конечно видеть нормальную структуру таблицы, а непросто наименование столбцов.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2016, 07:42 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=39244368&tid=1540332]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
169ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 256ms |
| total: | 513ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
