Зачем использовать нестандартные типы данных (datetime, user, geopt) в базах данных?

Question

[ssssergey]

Начал использовать Google App Engine. У них там в DataStore (БД) есть нестандартные Properties (типы данных) - datetime, user, geopt. Я пользы от них не заметил никакой (пока), а вот проблемы есть, например сериализация в JSON. Конечно это решается написанием своего Encoder-а. Но все-таки ... Если бы я сейчас заново создавал таблицу (там она называется Kind), то скорее всего вместо datetime использовал просто integer (unixtime), вместо user - string (nickname, а потом был получал объект user делая запрос по модулю users), вместо geopt - две колонки latitude и longitude. Так получается меньше ненужных телодвижений потом, при непосредственном использовании этих данных. Потому что из unixtime и в Питоне, и в JS и в Африке можно получить datetime.
Но ведь и в более привычных СУБД типа Postgresql тоже есть подобные типы. Есть ли в этом смысл?

Comments

[Дмитрий]

Когда это datetime стала не стандартным полем? Всегда было стандарт.

Answer 1

[nirvimel]

Смысл в том, что открывается возможность выполнять преобразования данных на стороне сервера без предварительной выборки. Например, можно быстро отфильтровать записи, с отметками времени, относящимися к определенному дню недели (за все время), произвести агрегацию данных в других полях и вернуть результат одной записью. С датой в unixtime в поле integer пришлось бы или вытаскивать полностью всю таблицу на клиент и там считать, или писать огромный велосипед на хранимых процедурах на сервере (и все равно это будет медленнее, чем встроенные функции, у которых предусмотрена даже оптимизация при поиске по индексу).
С географическими координатами все еще интереснее. Как вы себе представляете задачу поиска/выборки всех, объектов в заданном радиусе от заданной точки, если координаты в таблице заданны широтой и долготой в полях integer? На плоской поверхности это еще относительно легко (все равно фильтрация пойдет в два этапа (с подзапросом, например), и на первом этапе будет выбираться много лишнего, так как целочисленные индексы не могут на лету фильтровать по вычисляемым выражениям). А что если радиус поиска/фильтрации измеряется сотнями и тысячами километров? Засада тут в том, что Земля то не плоская ... А для географических координат (как специальный тип данных) для этого существует специальная функция, в которой все это уже предусмотрено и решено, а еще под этот тип данных существует специальный тип индекса, позволяющий производить поиск и фильтрацию с меньшей вычислительной сложностью (то есть намного быстрее), чем по двум индексированным полям integer.