Комментарии 10
Вы похоже топик 2 раза запостили.
Поразительно, даже в такой рутине нашли что-то интересное)
Объясните, пожалуйста, в чем смысл использовать хранимые процедуры? Я не наезжаю, просто правда не понимаю)
Мне всегда казалось, что из-за них логика рассредотачивается по разным местам, их по-нормальному не поместишь в систему контроля версий, а язык там — со всяческими ограничениями.
А задачка, как мне показалась, на уровне школьной информатики) Интересен только сам факт наличия всяких схем учета стажа.
Мне всегда казалось, что из-за них логика рассредотачивается по разным местам, их по-нормальному не поместишь в систему контроля версий, а язык там — со всяческими ограничениями.
А задачка, как мне показалась, на уровне школьной информатики) Интересен только сам факт наличия всяких схем учета стажа.
Мне всегда казалось, что из-за них логика рассредотачивается по разным местам, их по-нормальному не поместишь в систему контроля версий, а язык там — со всяческими ограничениями.
Попробуйте сказать это программистам PL/SQL :) Логика на сервере — это очень хорошо. Не хочу показаться невежливым, но в этом вопросе — «чтобы понять, надо гонять» :)
Системы контроля версий для этих языков тоже есть.
И всетаки один аргумент приведу — в больших промышленных БД перед/после каждого insert, update, delete надо сделать большую кучу проверок. Часто они затрагивают большие объемы данных. Хранимая процедура все эти данные «крутит» в том же месте, никуда их особо не перемещая. А на клиенте вы будете вынуждены при каждом «чихе» эти данные запрашивать. А клиент и сервер слишком часто не на одном компе. Аргументов кстати еще можно привести. Правда я ни разу не занимался программированием хранимых(только работал с такими людьми), поэтому не могу полностью аргументировать.
почему не поместишь? храните скрипты создания процедур в vcs, вместо «компиляции» такого «исходника» у вас будет отсылка запроса на сервер.
Язык может быть разный, зависит от СУБД. В PostgreSQL есть поддержка процедур на многих современных языках.
Язык может быть разный, зависит от СУБД. В PostgreSQL есть поддержка процедур на многих современных языках.
Если не ошибаюсь, хранимые процедуры при первом вызове компилируются и потом работают очень быстро. К тому же клиенту пересылается только ответ, а не куча данных, т.е. существенно экономится траффик когда сервер с базой данных отдельный.
НЛО прилетело и опубликовало эту надпись здесь
Ох уж эти кадровики-шаманы! Если стаж считается из расчета что в месяце 30 дней, итого 30*12=360 дней в году, а не 366 или 365. Зато нам считать легко: берем разницу в днях, делим на 30 — получаем месяцы, делим еще на 12 — годы.
Вот второй способ более реалистичный. Почти не отличается от нормальной разницы в месяцах или годах.
Вот второй способ более реалистичный. Почти не отличается от нормальной разницы в месяцах или годах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Расчет периодов стажа в MySQL