Год постройки

[VladSI 15]

Каким типом запись правильно записать? Чтобы потом в поиск можно задать от и до.

[TopRaN 235]

Каким типом запись правильно записать? Чтобы потом в поиск можно задать от и до.

тогда только safe_string

[VladSI 15]

тогда только safe_string

Как в фильтре поле будет реализовано? От года до года?

[TopRaN 235]

Как в фильтре поле будет реализовано? От года до года?

))) Это уже вопрос на миллион))) В зависимости от того как вы это видите, проще это два поля как с ценой.

[VladSI 15]

))) Это уже вопрос на миллион))) В зависимости от того как вы это видите, проще это два поля как с ценой.

Но тогда тип поля должен быть числительным.

Это понятно, что мы все уже миллионеры)))

 

 А есть формат года? YEAR

[abushyk 694]

Но тогда тип поля должен быть числительным.

Это понятно, что мы все уже миллионеры)))

 

 А есть формат года? YEAR

 

Такого формата нет. Но, если подумать, то формат YEAR - это тот же "целое число в приемлемом диапазоне, например больше 1900 и меньше 2100".

Хаком может быть заведение поля safe_string, наложение на него параметра rule (Type:int,Min:1900,Max:2100) как тут (но следует помнить, что задание минимального ненулевого значения фактически сделает поле обязательным к заполнению!) и принудительная смена поля этой колонки в БД в таблице re_data на INT. Последнее не обязательно, но позволит выиграть чуток на размере БД и размере строки записи в БД.

Поиск по нему естественгно сравнение на больше-равно и меньше-равно. А вид на форме - тут уже дело вкуса. От простого поля ввода "год постройки от", до двух диапазонніх полей или выпадалки в предустановленными диапазонами.

[VladSI 15]

Не моё

 

Использование календарных типов данный в MySQL

Начнем с самого простого — тип YEAR. Единственное его достоинство — малый размер — всего-то 1 байт. Но из-за этого действует строгое ограничение по диапазону допустимых значений (тип может хранить только 255 разных значений). Мне сложно представить практическую ситуацию, когда может потребоваться хранить года строго в диапазоне от 1901 до 2155. Кроме того, тип SMALLINT (2 байта) дает диапазон, достаточный в большинстве ситуаций для хранения года. А экономить 1 байт на строке в таблице БД в наше время смысла нет.

Типы DATE и DATETIME можно объединить в одну группу. Они хранят дату или дату и время с довольно широким диапазоном допустимых значений, независимую от установленной на сервере временной зоны. Их использование определенно имеет практический смысл. Но если требуется хранить даты исторических событий, уходящие в прошлое за Нашу эру, придется выбрать другие типы данных. Для хранения дат неких событий, потенциально выходящих за рамки диапазона типа TIMESTAMP (дни рождений, даты выпуска продуктов, избрания президентов, запуски космических ракет и т.д.), отлично подойдут эти типы. При использовании этих типов нужно учитывать один важный нюанс, но об этом ниже.

Тип TIME можно использовать для хранения промежутка времени, когда не нужна точность меньше 1 секунды, и промежутки времени меньше 829 часов. Добавить тут больше нечего.

Остался самый интересный тип — TIMESTAMP. Рассматривать его надо в сравнении с DATE и DATETIME: TIMESTAMP тоже предназначен для хранения даты и/или времени происхождения неких событий. Важное отличие между ними в диапазонах значений: очевидно, что TIMESTAMP не годится для хранения исторических событий (даже таких, как дни рождений), но отлично подходит для хранения текущих (логирование, даты размещения статей, добавления товаров, оформления заказов) и предстоящих в обозримом будущем событий (выходы новых версий, календари и планировщики и т.д).

[VladSI 15]

YEAR Год в двухзначном или четырехзначном форматах (по умолчанию формат четырехзначный). Допустимы следующие значения: с 1901 по 2155, 0000 для четырехзначного формата года и 1970-2069 при использовании двухзначного формата (70-69). MySQL выводит значения YEAR в формате YYYY, но можно задавать значения в столбце YEAR, используя как строки, так и числа (тип данных YEAR недоступен в версиях, предшествующих MySQL 3.22)

[abushyk 694]

1. Я тоже сторонник низкоуровневого программирования, но всем почему-то нужны интерфейсы, выпадающие списки, чекбоксы и прочая ерунда)))

2. Не уверен, что рационально поддерживать проекцию всех типов полей из мускула, так как их там очень много.