Официальный сайт — это www.firebirdsql.org.
Если я не ошибаюсь, официальной документации — нет. По сути документация по FB это дока по IB6 + RN от всех версий.
C pdo_firebird проблемы есть, но он и числится экспериментальным.
С php_interbase работать можно, единственное, что огорчает, это отсутствие поддержки RETURNING.
Реальный пример недельной давности.
Три ветки:
— текущая версия в эксплуатации (PROD)
— версия в тестировании (RC)
— основная разработка (HEAD)
В PROD-версии несколькими коммитами правятся баги и двумя коммитами мержатся в RC. При попытке за раз смержить в HEAD оба мержа PROD->RC получаем конфликт на свойстве svn:merginfo.
При непоследовательном слиянии, например, после бекпорта RC->PROD при слиянии PROD -> RC надо либо пропустить ревизию с бекпортом либо только зарегистрировать слияние. Ситуация усложняется было изменение дерева, tree conflict гарантирован.
уже говорили, но повторюсь, это не относится к очередям, но таки устраняет причину самих очередей, если бы реализовали прием документов на несколько специальностей за одним столом, сэкономили бы еще больше времени и себе и абитуриентам.
В свое время, после введения ЕГЭ, отказались от схемы — 1 заявление — 1 специальность. Именно по причине диких очередей и дикой загрузки персонала. Имея на руках результаты экзаменов, вместо заявлений на 1-2 специальности подавали на 3-5 и более, на всякий пожарный так сказать. В самые горячие дни принимали >300 заявлений на один факультет, вместо 17:00 прием заканчивали в 18-19 часов.
Позже стали брать один пакет документов, 1 заявление, в котором в порядке приоритетов перечисляются специальности (в разрезе формы обучения и формы финансирования). Усложнился процесс расчета рейтингов и зачисления, но эта проблема решаема. Зато времени и нервов, как одни так и другие, стали тратить меньше.
P.S.
в течение примерно 0,1 секунды кнопку «Следующий» нажали два секретаря
А если бы была общая база, со списком всех абитуриентов, их баллов, специальностей, на которые они подали, с указанием приоритета — и абитуриенты бы рассортировывались на максимально желаемые из возможных специальности?
была такая задумка… называлось это, если не ошибаюсь, Единый Конкурсный Прием (ЕКП)… дитя умерло не родившись.
К сожалению некоторые бюррократические примочки вроде «бумажного журнала регистрации абитуриентов» обойти не удалось (в этом году — в следующем будем стараться от него избавиться).
извините как?
вроде как, это требование, спущенное сверху. В бд можно сделать все что угодно, а в прошитом журнале, скрепленном подписями ответственных лиц уже нет.
Если я не ошибаюсь, официальной документации — нет. По сути документация по FB это дока по IB6 + RN от всех версий.
То что так делают некоторые тулзы, еще не делает этот способ официальным.
Процедуры вызывать можно, как и раньше. Я говорил про эту фичу.
С php_interbase работать можно, единственное, что огорчает, это отсутствие поддержки RETURNING.
это не сильно отличается от ковыряния внутри файла.
именно
Три ветки:
— текущая версия в эксплуатации (PROD)
— версия в тестировании (RC)
— основная разработка (HEAD)
В PROD-версии несколькими коммитами правятся баги и двумя коммитами мержатся в RC. При попытке за раз смержить в HEAD оба мержа PROD->RC получаем конфликт на свойстве svn:merginfo.
При непоследовательном слиянии, например, после бекпорта RC->PROD при слиянии PROD -> RC надо либо пропустить ревизию с бекпортом либо только зарегистрировать слияние. Ситуация усложняется было изменение дерева, tree conflict гарантирован.
равносильно
$x = isset($arr['x'])? true: null;
алкоголичноаналогично, коллегаа что там можно посмотреть, кроме самих баллов?
В свое время, после введения ЕГЭ, отказались от схемы — 1 заявление — 1 специальность. Именно по причине диких очередей и дикой загрузки персонала. Имея на руках результаты экзаменов, вместо заявлений на 1-2 специальности подавали на 3-5 и более, на всякий пожарный так сказать. В самые горячие дни принимали >300 заявлений на один факультет, вместо 17:00 прием заканчивали в 18-19 часов.
Позже стали брать один пакет документов, 1 заявление, в котором в порядке приоритетов перечисляются специальности (в разрезе формы обучения и формы финансирования). Усложнился процесс расчета рейтингов и зачисления, но эта проблема решаема. Зато времени и нервов, как одни так и другие, стали тратить меньше.
P.S.
select… for update
была такая задумка… называлось это, если не ошибаюсь, Единый Конкурсный Прием (ЕКП)… дитя умерло не родившись.
извините как?
вроде как, это требование, спущенное сверху. В бд можно сделать все что угодно, а в прошитом журнале, скрепленном подписями ответственных лиц уже нет.