Типы полей - даты

[Shicoo]

Типы полей - даты

Мне не понятно, зачем нужны типы полей - Date, Time, Datetime и другие им подобные, если для хранения этих данных можно использовать тип поля INT. Есть какие преимущества? я никаких описаний преимущества использования одного типа перед другим не нашел, кроме как то, что в timestamp можно установить текущую дату константой. Может кто-то объяснить или кинуть линк?

 

[Апокалипсис]

MYSQL::мануал

 

[akd]

Shicoo, если следовать такой логике, то нужно всего два типа поля varchar и текст. все остальные лишние.

"я никаких описаний преимущества использования одного типа перед другим не нашел" - головой можно не только есть.

 

[HraKK]

зачем текст и варчар?
LONGTEXT

 

[cDLEON]

Shicoo
А ещё можно еду в унитазе хранить. 8)

 

[Shicoo]

я понимаю, что логично хранить дату в Date а текст в char/varchar etc, просто у нас тут спор пошел стоит ли хранить дат именно в date, т.к. работать с ней легче, если хранить ее в int.

 

[Gas]

стоит, работать так-же просто, но правильней и нет гемороя с датами < 1970 г.

 

[Ralph]

Черт,а ведь автор темы прав... Кстати,отсюда вытекает еще одно логичное умозаключение-если база данных хранит данные все равно в файлах,то не проще вообще отказаться от БД ?
P.S. Ты думаешь,БД существуют только для ХРАНЕНИЯ данных ?

 

[Gas]

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

 

[Ralph]

Просто непонятно,ЧЕМ такое хранение даты проще...

 

[Апокалипсис]

блин, да храните как вам угодно дату

 

[Mols]

Чего вы набросились на человека ?
Есть преимущества при хранении времени и даты в соответствующем типе. Смотри все функции для работы с датами и временем.
Всё зависит от конкретной ситуации. Иногда может быть действительно разницы и нет.
Но вот например если нужно выбрать историю каких либо событий занесённых в базу скажем 15 октября за последние 20 лет... или каждый понедельник текущего года... ну попробуй это всё через инт выкрутить. Не то, чтобы я сомневаюсь в возможности этого при хранении даты в инт... но сам понимаешь как минимум код станет более громоздким иногда более сложным в понимании и т.д.

 

[Ralph]

А если отвечая на первый вопрос-потому что так удобнее,а базы по моему мнению созданы как раз для повышения удобства.Я к примеру столяр и мы работаем с миллиметрами,но людям привычней метры и сантиметры,и поэтому для удобства пользователя именно я перевожу при приеме заказа,что 2 метра 25 с половиной сантиметров это будет 2255 миллиметров,а не заставляю это делать заказчика

-~{}~ 07.12.07 19:24:

Соответственно мне проще написать WHERE birthday>NOW()-INTERVAL 1 WEEK чем высчитывать,столько секунд в сутках,умножать на семь...

 

[Gas]

как минимум код станет более громоздким

особо не станет громоздким, ну добавится unix_timestamp() или from_unixtime().

я не пропагандирую за int, наоборот, но раньше работал с ним так-же как и c datetime не испытывая ограничений (кроме озвученных выше).

просто на такой вопрос фразы:

"умозаключение-если база данных хранит данные все равно в файлах,то не проще вообще отказаться от БД ?"

или

"если следовать такой логике, то нужно всего два типа поля varchar и текст."

явно не в тему.

 

[Фанат]

Gas
в тему-в тему.
поскольку они повторяют рассуждения автора. умозрительные.

 

[fixxxer]

достаточно вообще нуля/единицы и 4х основных операций.

 

[nerezus]

и 4х основных операций

/me представил тело микрокомманды mul(хотя бы), написанную на пхп ))