Поиск по «графику работы»

храни «с» и «по» в секундах, начиная с 00:00. ну или «номер дня недели + кол-во секунд» в каждом из полей «с» и «по». связь один ко многим получается, 1 человек - набор интервалов. потом из этого можно любые условия проверять.

а вообще используй постргрес

по шапке тебе за хранение в секундах. В mysql всё, что он описал, выбирается стандартными функциями для времени, при хранении в datetime/timestamp. Или в вашем постгрессе такого нет? Или ты не знаешь, но советуешь?

я просто сталкивался с такой задачей - в бытность мою разработчиком приходилось поддерживать такой функционал. и реализован он была так же коряво, как ты предлагаешь. ну или почти так же. если нужно хранить график работы, то тип date/datetime не подходит, потому что записывать «вторник» как «1970-01-06» - тупняк. можно использовать time для хранения смещения от начала недели, но работа с int традиционно быстрее во всех субд (хотя тут не уверен), а unix timestamp - это именно int. я, может, чего-то не знаю в этих ваших мускулях, но если речь идет не о лабораторной поделке, а о промылшенном решении, то мой вариант - ок.

именно timestamp (не дейттайм) да, инт юникстайма. Смысл в том, что скорость работы остаётся прежней, но в нагрузку становятся доступны очень удобные фунции, собственно, для вычисления смещений, диапазонов, и просто. Если же очень нужно, можно забрать это юникстаймом. Наоборот же - нельзя. Избегать инструмента, который сделан специально под задачу - это странно, на это должны быть какие-то сверх-основания.

Не ок, в общем. http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html

с интами - всё равно приходится делать аналоги этих функций, так нафига перекладывать то, что уже умеет база на свой повтор?