лаб 7

[lasbio]

1 - в принципе правильно, но будет проще, если передать в качестве аргументов memid и slots. 2-5 - не выполнено

[lasbio]

2 - (а) включите в скрипт все создаваемые структуры.
(б) надо защитить от удаление уже оплаченное, у Вас наоборот (в) зачем case в TRIGGER on_pay_status? там всего одно действие по условию, т.е. достаточно IF. (г) Что будет если payed = 1 при insert? 3-5 - не выполнены.

[Nigota]

2 (в) - если в bookings будет меняться другая колонка (не payments), то тригер все равно сработает - он вообще срабатывает на любые изменения в bookings. По заданию необходимо отслеживать только колонку payments, за это у меня отвечает строка WHEN NEW.payed = OLD.payed THEN BEGIN END; , ну и у колонки payments может быть 2 состояния (True or False), суммарно надо отслеживать 3 состоя - CASE с этой задачей справляется лучше, чем IF, к тому же CASE удобно использовать в плане масштабируемости условий. Считаю, что целесообразнее использовать CASE

2 (г) - не понял вопроса. INSERT происходит после того как payed уже стала 1

[lasbio]

1 -возвращаемый тип?

2в - в замечании была неточность. Оно относится к триггеру before delete. Использование там case необоснованно, т.к. для проведения действия запрета надо проверять единственное условие payed = 1. Впрочем и для другого триггера можно легко написать все через IF (new <> old) then begin if new = 1 then ... else ... end. Впрочем это дело вкуса для данного триггера.

2г - если пользователь оплатил аренд сразу, то в таблицу booking по INSERT внесена запись с payed = 1. Она в вашу таблицу payments не попадет.

Зачем нужен SELECT в INSERT ... SELECT NEW.bookid, cost_of(memid, facid, slots) FROM bookings WHERE bookings.bookid = NEW.bookid LIMIT 1;

У Вас в триггере и так значения bookid, memid, facid, slots известны и для NEW И для OLD. 3 - процедура должна быть индифферентна относительно параметров, т.е. должна совершать расчет за любой месяц. ЕЕ в качестве демонстрации работоспосjбности надо было применить в июлю. Кроме того, в задании указано "каждого объекта клуба" а у Вас сделано для всех. 4-5 - не сделано

[lasbio]

1 - не поправлено (соответственно ошибки в 2 и 3, где эта функция использована). 2 - в принципе правильно, но:

• зачем нужно было создавать payments.bookid и делать AutoInt для payid? На одну запись bookings приходится не более 1 записи payments, т.е. можно было использовать bookings.bookid в качестве значения которое записывается в payments.payid.
• не создан FK (Foreigh Key), который был задан по заданию. Заодно подумайте, может быть и триггер на удаление не будет нужен если FK создать с определенными опциями?
• Не совсем понимаю Вашу приверженность CASE. Формально использование CASE или IF это личное предпочтение, т.е. на производительность не влияет, но если у Вас одно условие (как в триггере on_insert), то код с IF значительно короче. 3 - верно, но
• не совсем понятно зачем в качестве входного параметра дата если по условию месяц и год.
• не совсем понятно зачем кроме суммы возвращать название объекта если на входе задано curfacid, т.е. ясно что для того чтобы считать сумму уже обратились к таблице facilities. название объекта имеет смысл выводить только если процедура будет считать сразу по всем объектам суммы за месяц, т.е. выводить таблицу а не одну стороку. 4 - не завершено, слишком сложно (по логике). Нет никаких оснований предполагать что соотношение гостей и членов на последующие периоды будут отличаться от того, что имеется по настоящему. В задании нет указания менять соотношение оплат для гостей и членов, значит оно остается неизменным. Следовательно, увеличение/уменьшение срока окупаемости может быть только за счет увеличения/уменьшения в равное кол-во раз цен на аренду. Единственно, надо учесть, что должно быть зафиксировано уже ранее оплаченное, т.е. изменение цен действует только на период с дня расчета. А до него оно фиксировано и неизменно (это уже история). 5 - не выполнено

[Nigota]

Исправил ошибки. Закинул 8 лабу. идею 4 задания я понял (ну я так и делал, просто не дописал функции)

[lasbio]

5 - не выполнено 4 - подход не верный, неявные ошибки. Все существенно проще, чем Вы делаете:

• зачем ввели starttime, endtime? Разве это есть в задании? В Задании указано "на последующие месяцы", т.е. у Вас определена единственная дата и это current_time. от этого дня нужно считать по новым ценам, а до него - по старым.
• зачем считать соотношения гостей и членов? Ясно, что поскольку расчет идет "средневзвешенный" по всему предыдущему периоду, то естественно предполагать, что соотношение гостей и членов не изменится, т.е. их среднее количество в день при расчете последующих периодов оплат неизменно. Поэтому, если задано уменьшить/увеличить окупаемость в каппа раз, то то эквивалентно синхронному уменьшению/увеличению стоимость аренды как гостя, так и члена клуба в бетта раз. И единственно, что нужно сделать, это найти как связаны между собой каппа и бетта. Это тривиальная задача, сводящаяся к следующим шагам (для заданного объекта facid): (a) income == доход за все время эксплуатации объекта без учета обслуживания; (б) maintenance == расходы на обслуживание за все время эксплуатации объекта (с точностью до дня); (в) net-income == income - maintenance (особый случай когда <= 0 ,никогда не окупится, т.е. каппа невозможно определить - выход по ошибке) (г) если стоимость объекта cost <= net-income, то далее считать ничего не нужно, объект уже окупился, т.е. бетта == 1. (д) period == период эксплуатации в днях, т.е. c самой первой аренды до current_time. (е) day-net-income == net-income /period (в принципе можно это посчитать сразу используя avg, то тогда можно пропустить случай (г), либо его все равно нужно будет проверять через нахождения периода и т.д.). или, по другому, day-net-income = day-income - day-maintenance, где, соответственно, day-income = income/period, day-maintenance = maintenance/peiod. (ж) окупаемость (в днях) ok-old= cost / (day-income - day-maintenance) (з) новая окупаемость ok-new = каппа ok-old (и) day-income-new = day-income бетта - это доход в день за периоды > current_time, т.е. ok-new = (cost - net-income)/(day-income бетта - day-maintenance). или, если собрать все вместе, то бетта == (1 / каппа) (cost - income + maintenance) / cost * (1 - maintenance / income) + maintenance / income. Видно, что достаточно посчитать (а) и (б), проверить пару условий и вычислить бетта по заданному каппа (и все в одной функции), а не "городить огород" из множества функций.
  Совет - любую задачу надо начинать с "конца", если есть мат.решение, то оно самое короткое. Его и надо запрограммировать. P.S. приведенное "решение в лоб" не единственное. То же самое можно получить через вычисление средних и учет периодов оплат.

[lasbio]

3 - считает чистый доход, а не окупаемость. окупаемость == период , в течении которого суммарный чистый доход превысит начальную стоимость объекта. 4 - не верно. Функция возвращает не то что задано в задании и не в том формате. Кроме того, зачем использовать "income - maintenancу" в beta если выше уже задано net_income ? И до beta <0 функция никогда не дойдет по условиям выше. 5 - см. 4, нет сравнения