Сергей Горностаев: я думаю, что руководство не понимает, что правило работает и в другую сторону: если работник отметился в системе в 08:59:59, то через секунду ему засчитается отработанный час. При этом если он уйдет домой в 17:00:00, то ему засчитаются полные 9 часов рабочего времени. И этот факт работники поймут очень быстро.
Если руководство занимается такими вещами, бегите оттуда.
Сергей Горностаев: в минутах, потому что погрешность больше. datediff считает только полные часы, поэтому, если сотрудник работает в среднем 8 часов, но иногда уходит на 10 секунд раньше, то в эти дни последний час ему не засчитается.
в вашем where нет возможности использовать индекс по coming_time. Создайте такой индекс, добавьте пару десятков тысяч записей и увидите разницу.
в минутах считайте, а в приложении показывайте как хочется.
мой перфекционист плачет кровавыми слезами, глядя на ваше where. Так лучше:
where coming_time >= dateadd(month, datediff(month, 0, getdate()), 0) --начало месяца
and coming_time < dateadd(month, datediff(month, 0, getdate()) + 1, 0) -- конец месяца
Максим Федоров Хотя решение хранить картинки в базе так себе решение, у вас плохо с аргументацией.
1. Кеширование решит эти вопросы. Причем кеширование используется и не для катринок тоже.
2. Объем таблицы в базе ограничен операционной системой и прежде чем этот лимит будет достигнут, у вас будет инвестор, который даст денег на новый сервер. Конечно же хостер может ограничивать размер базы, но мы не знаем, насколько это касается ТС.
3. Почему нельзя сортировать и делать выборки над картинками, тоже непонятно
4. Что же помешает кешированию?
5. Если реплицировать базу, то вот вам и много серверов. Если же вы имеете ввиду разделение картинок по хостам, то можно все хосты img1.domain, img2.domain и т.д. отдавать физически с одного хоста. И это вообще не проблема для обсуждаемой темы.
Хранить картинки в базе это специфическое решение, где нужно понимать плюсы (а они есть) и минусы. И в каждом конкретном случае взвешивать аргументы.
Денис Никитин: там разработчик nagios не сильно развивал проект и каждый коммит через себя пропускал, когда надоело и накипело, все разосрались и часть разработчиков стала работать над форком. В итоге icinga более богата фичами, чем nagios.
Daeamon: да, вроде так. Можно еще distinct убрать и к форматированию придраться, но если это заработает, тем более с динамическими названиями таблиц, это будет ваш триумф.
Daeamon: простите, но если вы не знаете синтаксис sql, то я вижу только 2 варианта: вы его начинаете учить или нанимаете специалиста.
А по запросу, что вы написали, то там вы не соблюли синтаксис. Надо примерно так:
where exists (select * from table where <условие>)
and exists (select * from table where <условие>)
Но на мой взгляд, без понимания как это будет работать, вы не сможете решить эту задачу.
Daeamon: все еще полный ппц.
1. Вы используете алиасы для таблиц для того, чтобы запрос было легче читать?
2. Подзапросы в where бессмыслены. От того, что вы перенесли их во временную таблицу они быстрее не стали. Таблица Variable уже присоединена, используйте OR
3. Когда пишете запросы старайтесь избегать горизонтального скролла
4. Возвращаясь к Variable: уберите ее из join и добавьте в where подзапросы с exists:
and exists (select * from Variable v where v.VariableID = Vv2.VariableID and VariableName in ('Условное_обозначение', 'Footprint' /*etc.*/)) Алексей: Условия надо писать в where, а условия соединения в join. Это улучшает понимание запроса и как следствие упрощает оптимизацию. То что можно и наоборот не значит, что так делать нужно.
entermix: я не на собеседовании, и на ваш вопрос отвечать не буду. Не обижайтесь. Я правда не понимаю, почему вы задаете вопросы не по делу. У вас там в highload может быть только вставка данных, а вся аналитика по сути вещь в оффлайне, то есть для ее создания безразлично сколько времени длится запрос и что он там блокирует. Как я уже заметил, можно создавать таблицы хоть на каждый час. А благодаря партиционированию все это достаточно просто настраивается и автоматизируется. Еще раз: в чем вы видите сложность моего решения?
entermix: я не понимаю, в чем вы видите проблему.
select event, date, count(*) from user_action where date bewteen '20150101' and '20160101'
group by event, date
вот я не понимаю на хрена устанавливать LAMP не через менеджер пакетов.
Можно поставить только mariadb-server и phpmyadmin. Все остальное подтягивается по зависимостям. Это работает и проверено уже много десятков раз. Не работать это может в случае ошибок в установке (что маловероятно) или при ручной правке конфигов (например подключили левый репозиторий). Делайте выводы. А конкретно по ошибке: она значит, что обработчик файлов php не подключен. Это можно решить костылем, а можно найти причину.
Для разработки в php начиная с 5.4 есть встроенный веб-сервер. запускается командой
php -S localhost:8000
это сделано специально для того, чтобы разработчики не занимались конфигурированием.
