- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
$statement = $pdo->prepare(
"if not exists
(select daily_serving_start, daily_serving_end,
weekly_service_off, one_time_service_off
from menu_availability_rules
where
(daily_serving_start = :start0 or
(daily_serving_start is null and :start1 is null)) and
(daily_serving_end = :end0 or
(daily_serving_end is null and :end1 is null)) and
(weekly_service_off = :weekly0 or
(weekly_service_off is null and :weekly1 is null)) and
(one_time_service_off = :once0 or
(one_time_service_off is null and :once1 is null)))
begin
insert into menu_availability_rules
(daily_serving_start, daily_serving_end,
weekly_service_off, one_time_service_off)
values (:start2, :end2, :weekly2, :once2)
end
if not exists
(select menu_id, daily_serving_start, daily_serving_end,
weekly_service_off, one_time_service_off
from menu_availability
where
menu_id = :menu_id0 and
(daily_serving_start = :start3 or
(daily_serving_start is null and :start4 is null)) and
(daily_serving_end = :end3 or
(daily_serving_end is null and :end4 is null)) and
(weekly_service_off = :weekly3 or
(weekly_service_off is null and :weekly4 is null)) and
(one_time_service_off = :once3 or
(one_time_service_off is null and :once4 is null)))
begin
insert into menu_availability
(menu_id, daily_serving_start, daily_serving_end,
weekly_service_off, one_time_service_off)
values (:menu_id1, :start5, :end5, :weekly5, :once5)
end");
Follow us!
Ключи юзать. Даже если NULL-ы мешают - можно добавить специально колонку для чего-то вроде хеша по этим 4-5 параметрам, чтобы база могла уникальность проверить.
ЗЫ. В переменную - не получится, это разные таблицы, если уж на то пошло. Просто в одной таблице ФК = юник из из другой таблице, ну и имена соответственно такие же, но это опять, же не имеет значения, этой таблицы уже несколько часов как не существует вообще - нашелся способ ее удалить и распихать остатки туда, где они должны были быть изначально. Печаль же осталась...
Когда я смотрю документацию, или примеры, то там тоже, кто с какой ноги утром встал, тот так и написал. Поэтому, а что делать?
P.S. Почти всегда есть альтернатива переписать благодатнее в insert-into-select-from.
Как-то так. Практический смысл этих двух таблиц: в одной хранятся "правила", когда ресторан не продает какой-то из пунктов меню, а вторая таблица - ассоциация правило-меню. Врезультате переделалось с добавлением колонки id в таблицу с правилами, и второй ФК теперь по ней.
И написанием утилитных функций, которые сами создают поля типа $foo#, и запихивают сколько нужно аргументов :|
В заголовке PHP, код на 95% состоит из sql, а выглядит как лисп.
Повеселило.
>А что делать?
Использовать хранимые процедуры? Выносить запросы в отдельный файл? Не форматировать как S-выражения?
Поскольку JS довольно сильно похож на Scheme, возможность построения астракций с его помощью сложно подвергнуть сомнению.
Другое дело, что любой гибкий и мощный инструмент в руках идиотов легко превращается в сами знаете что.
Например, чуть ли ни единственная универсально используемая библиотека ж. квери является по сути и задумке божественным объектом (одним, чтобы не дай бог пользователи не запутались), и вереницей, по сути ставших глобальными, методов этого объекта.
Приложениям на ж. скрипте не свойственны иерархии, вообще никакая структура. Это как правило большой список функций.
Еще такой момент: когда в Яве используется import, или use в ПХП и им подобные - в еденице программы, программист достаточно четко представляет, что ему тут доступно. В ж. скрипте в любом месте программы доступно все, и соответственно, программа становится неуправляемым монстром из кучи отдельных участков кода, которые никак не связаны между собой. Повторное использование кода в такой ситуации стремтися к нулю. Скорость разработки падает не пропорционально размеру проекта, а, возможно даже там какая-нибудь квадартичная зависимость (т.е. разработать проект в два раза более сложный чем проект Х займет не в два раза больше времени, а, возможно, в четыре).
Кроме того, чтобы разрешать строительство абстракций, язык должен так же больно наказывать за их игнорирование. В ж. скрипте наказание приходит очень поздно.
Модули в JS прекрасно заменяются объектами. В Python, к примеру, модули тоже по сути - обычные объекты-синглтоны.
> Приложениям на ж. скрипте не свойственны иерархии
Flat is better than nested. Иерархии нужны не всегда. Да и объекты могут содержать объекты, поэтому иерархии всё-же возможны.
> разработать проект в два раза более сложный чем проект Х займет не в два раза больше времени, а, возможно, в четыре
Это не зависит от языка программирования. Это общее свойство всей разработки ПО.
Позвольте предложить такую критическую мысль: если проект занимает в 4 раза больше времени, то он в 4 раза сложнее, а не в 2, а начальная оценка была попросту неверной.
И, как уже заметил Роман, выбор ЯП тут ни при чем - просто сроки для больших проектов оцениваются неверно. Интересная книга по теме: "Факты и заблуждения профессионального программирования" Р. Гласс.
Модули не заменяются объектами... это, как заменить сахар стиральным порошком...
Иерархии, или вообще хоть какая-то структура нужна большим приложениям. Если бы это было не так, люди бы по-прежнему писали на ассемблере все, не создавая никаких структур над ним.
Как говорил Буш младший: read my lips, проетк в два раза сложнее написать в четыре раза сложнее, проект в три раза сложнее - в девять раз сложнее, проект в четыре раза сложнее - в шестнадцать раз сложнее. Это делает написание проектов среднего-большого размера на ж. скрипте бессмысленной тратой времени и человеческих ресурсов - дешевле написать транслятор с той же Явы, и нагенерить говно ж. скрипта, но временные и человеческие затраты будут линейными.
И временные / человеческие затраты взяты по отношению к другим технологиям, а не по отношению к какой-то произвольно выбранному "оптимальному" соотношению.
Я это говорю как человек, который имел возможность разрабатывать одно и то же приложение на Флеше и потом на ж. скрипте. Т.е. в такой ситуации обычно второй раз занимает минимум времени, т.как UOD уже известен, ETL в принципе уже большей частью сделан и т.д. И тем не менее, просто разработка ж. скрипта заняла неимоверно больше, чем оригинальная разработка на Флексе / Флеше.
Если интересно - речь идет о системе бух. учета / администрирования для British Airways.
eLisp не особо сильно отличается по сути от scheme, на самом деле (с моей точки зрения) он во многом хуже в плане модульности и структуризации приложений. Тем не менее, на нём написано очень внушительное приложение, которым я пользуюсь каждый день.
В каждом подобном споре я хочу донести одну и ту же мысь: язык сам по себе редко бывает виноват в косяках программиста. Я твёрдо уверен, что язык для отличного программиста должен существенно отличаться от языка для типичных раздолбаев. Я не скажу, что Java лучше, чем JavaScript. It depends. Даже для крупных приложений.
Я написал достаточно кода на Java, чтобы её недолюблибливать, но у неё есть ощутимые преимущества в виде сотен работающих библиотек и чрезвычайно развитой инфраструктуры.
К примеру, emacs бы только выиграл, если бы основным языком расширений был JavaScript, была бы только возможность сохранить макросы и аспекты (с аспектами вроде проблем нет, а вот макросы перенести сложнее).
И да, монструазный eclipse, написанной на "божественной" жабе, я люблю гораздо меньше.
Если бы в еЛиспе сделали человеческие пакеты / неймспейсы и взялись немного за оптимизацию байткода, то получился бы вполне конкурентноспособный язык, сравнимый с Питоном или Руби. ж. скрипту до этих языков еще милю лесом, но он даже и не двигается в нужном направлении.
А ведь есть ещё язык C, в котором нет ни пакетов, ни пространств имён, ни сборщика мусора, ни намёка на классы, ни встоенных высокоуровневых структур данных, ни удобной интерактивной среды. И типизация там оставляет желать лучшего.
И представляете, люди пишут на этом весьма работоспособные программы весьма внушительных размеров.
Всё зависит от программиста.