Эволюция, и куда она так и не дошла

[justy_tylor]

После выездного семинара CDO, где дни и ночи играли капоэйру, танцевали форро и вели прочий нездоровый образ жизни, вернулся в Питер, в котором уже целый день ничего не происходит. В связи с этим, даже о(б)суждение в почте с ailev статей от некоторых авторов, застрявших в профессиональном развитии лет на 30+, зацепило и привело к переоценке ценностей и

Comments

[livelight]

Я каждый день прохожу мимо рекламы, предлагающей купить жильё по цене сколько-то "руб. кв. / м."
Рубли квадратные за метр.
А ты говоришь, килограммы сохранить в SQL-базу, которая явно не обязана быть умнее, чем люди.

[justy_tylor]

Речь о том, что в SQL проще сделать квадратные рубли, чем сделать правильно. А это уже ахтунг.

[evtuhovich]

Я не очень понимаю, за что вы так невзлюбили БД. Касательно кастомных типов, то вот, например, http://www.postgresql.org/docs/9.2/static/xtypes.html так это может быть реализовано в postgresql. Немного C и сразу вам и сортировка, и агрегация и все, что угодно, что дает "обычная" БД.

Безусловно, я понимаю дополнительные расходы, связанные с использованием БД, но в вашей схеме прозрачного сохранение объектов совсем мало рассказывается о тех традиционных задачах, которые решаются с помощью БД.

И если добавить возможность индексирования, отказоустойчивость, катострофоустойчивость, а так же возможность делать худо бедно какую-то отчетность по бизнес объектам, то, возможно, получится система, которая по своей прожорливости обгоняет любую БД.

[justy_tylor]

Введение каждого типа через ручную перестановку битов на сях... нельзя развидеть...

[metaclass]

Отсутствие sum и функциональных типов в SQL вызывает желание выдавить себе глаза и разработать базы данных с нуля. Слава богу, там хотя бы product types есть.
А еще дичь с разницей в реализациях.

[justy_tylor]

Когда-то я считал это нормальным. Кейсы, связанные с SQL, попадались сильно нетиповые, и было ощущение "это ок, что там неудобно работать с графами, с геометрией, с ..., для других задач делалось". Дебит, кредит, формы, Адрес1, Комментарий23, magic numbers во все поля, только не перепутать, где по дефолту ноль, а где единица/ноль-и-единица/пустота/прочерк/пентаграмма, а так прекрасно ведь всё впихивается. Но потом задумался, как это же могло выглядеть в нормальных типах, и понял, что для "других" задач кормления вендоров и DBA всё таки сделано по высшему разряду.

Об отсутствии типов в БД

[livejournal]

User metaclass referenced to your post from Об отсутствии типов в БД saying: [...] http://justy-tylor.livejournal.com/195108.html [...]

[ext_910809]

Кстати, XML Schema на мой взгляд это примерно тот же уровень. Т.е. недалеко ушло от баз. И также широко используется для описания "типов данных".

А с ними вместе - WSDL, SOAP и прочая и прочая.

[ailev]

Затрагивая проблемы прозрачной персистенции: http://djb-scala.livejournal.com/1395.html?thread=1395#t1395

[justy_tylor]

Знакомо.

Когда-то размышлял, зацепился за эту тему. Начальные предпосылки схожие. Для бэкапа достаточно лога меняющих состояние базы вызовов API, для горячей реплики сервера достаточно параллельного реплея этого лога на реплику. Можно избавиться от груза легаси, сделать всё не как всегда, а очень красиво и минималистично и... Довести такую вещь до состояния технологии можно только на реальном highload проекте, с множеством часов отладки и тюнинга, когда есть спецы, сильно увлечённые отладкой и тюнингом. Надеюсь, что личные/социальные ресурсы avlasov позволят сорганизоваться с чем-то подобным.

[ailev]

Я тоже очень надеюсь.

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

[justy_tylor]

На весь вычислительный мир ресурсов не хватит. Я занимаюсь только теми фрагментами, которые подходят по опыту, доступному времени и перспективам.

Например, сейчас это бинарный протокол с открытым словарём, где более-менее решён вопрос работы с типами первого порядка, но надо найти решение с синтезом типов-из-типов на базе прототипов и GADT.

Обычна ситуация, когда базовый тип является общим (например, у всех есть какой-то vector3d x y z для декартовой системы координат в трёхмерном пространстве), а точность представления значений (float, double, ...), единицы измерения и ориентация осей (Y-Up вариант в Maya, пара разных Z-Up вариантов в 3DSMax и DIrect3D, etc) варьируется между реализациями. Сохранение связи между базовыми типами (и целыми базовыми модулями) и их более детальными вариантами в реализациях ведёт к возможности автоматического мэппинга между реализациями. Хорошая плюшка, заслуживающая некоторого времени на дизайн.