Подходит ли CouchDB лучше всего для динамических языков?

Question

я знаком с CouchDB и сразу же пришла идея сопоставить его результаты с объектами Scala, а также найти какой-то естественный способ взаимодействия с ним.

Но я вижу, что динамические языки, такие как Ruby и Javascript, очень хорошо справляются с подходом CouchDB, ориентированным на json/документ/без схем.

Есть ли хороший способ работать с Couch на статических языках?

Answer 1

Я понимаю, что CouchDB работает исключительно с объектами JSON.Поскольку JSON не типизирован, возникает соблазн поверить, что он более естественно подходит для динамических языков.Однако XML, как правило, также нетипизирован, и Scala имеет очень хорошую библиотечную поддержку для создания XML и управления им.Для изучения возможностей XML Scala см.: http://www.ibm.com/developerworks/library/x-scalaxml/

Аналогично и с JSON.При правильной поддержке библиотеки работа с JSON может показаться естественной даже на статических языках.Один из подходов к работе с данными JSON в Scala см. в этой статье: http://technically.us/code/x/weaving-tweed-with-scala-and-json/

В случае объектных баз данных в целом иногда удобно определить «модель» (используя, например, класс языка) и использовать JSON, XML или какой-либо другой нетипизированный язык документов в качестве сериализованного представления класса.Правильная поддержка библиотеки может затем преобразовать сериализованную форму (например, JSON) в структуры данных в памяти со статической типизацией и всеми плюсами, которые с ней связаны.Один из примеров этого подхода см. в разделе Lift’s Record, в котором добавлены преобразования в JSON и из него: http://groups.google.com/group/liftweb/msg/63bb390a820d11ba

Answer 2

Интересно, правильный ли вопрос вы задали?Почему вы используете Scala, а не динамические языки?Вероятно, из-за некоторых важных для вас достоинств, которые предоставляет вам Scala, и, я полагаю, качества вашего кода.Тогда почему вы не используете «статически типизированный» (т.е.база данных на основе схемы)?Еще раз я просто предполагаю, но на ум приходит способность реагировать на изменения.Базы данных производственного SQL имеют ужасную тенденцию: их очень сложно изменить и провести рефакторинг.

Так что ваши данные слабо типизирован, и ваш код является строго типизированным.Но где-то вам придется совершить переход.Это означает, что где-то у вас будет «схема» для ваших данных, хотя в базе данных ее нет.Эта схема определяется классами, с которыми вы сопоставляете документы Couch.Это имеет смысл;большинство применений Couch, которые я видел, имеют такой ключ, как «тип», и для каждого типа есть по крайней мере некоторый общий набор ключей.Следует ли вручную сопоставить JSON с этими классами Scala или использовать, например.причудливые инструменты отражения (медленнее, но красивые) или еще какие-то более причудливые функции Scala, с которыми я пока не знаком, — это деталь.Начните с простого, но медленного, а затем посмотрите, достаточно ли он быстрый.

Самое важное происходит, когда ваши занятия, т. е.твоя схема, изменять.Вместо ALTER ваших таблиц вы можете просто изменить класс, убедиться, что вы сделали что-то разумное, если для какого-то документа отсутствует ожидаемый ключ (поскольку он основан на более старой версии класса), и все готово.Реагировать на изменения еще никогда не было так просто, и при этом ваш код остается настолько статически типизированным, насколько это возможно.

Если вас это не устраивает и вы вообще не хотите никакой схемы, то вы фактически говорите, что не хотите использовать классы для определения и манипулирования вашими данными.Это тоже нормально (хотя я не могу представить себе применение), но тогда вопрос не в динамических и статических языках, а в том, использовать ли объектно-ориентированные языки на основе классов вообще.