Разнообразны ли базы данных и функциональное программирование?

Ответ 1

Прежде всего, я бы не сказал, что CLOS (Common Lisp Object System) является "псевдо-OO". Это первый класс OO.

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

Вы не можете без сохранения данных хранить данные, а функция - поток данных и не нуждается в состоянии.

Если у вас есть несколько проблем, смешанных, смешайте свои парадигмы. Не ограничивайте себя только использованием нижнего правого угла панели инструментов.

Ответ 2

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

При рассмотрении доступа к базе данных существуют три основных аспекта: целостность данных (почему все бизнес-правила должны применяться на уровне базы данных не через пользовательский интерфейс), производительность и безопасность. SQL написан для более эффективного управления первыми двумя соображениями, чем любой язык интерфейса. Потому что это специально предназначено для этого. Задача базы данных намного отличается от задачи пользовательского интерфейса. Неудивительно, что тип кода, который наиболее эффективен в управлении задачей, концептуально отличается?

И базы данных содержат информацию, критическую к выживанию компании. Неудивительно, что предприятия не хотят экспериментировать с новыми методами, когда их выживание поставлено на карту. Многие компании не желают даже обновляться до новых версий своей существующей базы данных. Таким образом, в дизайне базы данных существует присущий консерватизм. И это намеренно так.

Я бы не стал писать T-SQL или использовать концепции дизайна базы данных для создания вашего пользовательского интерфейса, почему вы пытаетесь использовать язык интерфейса и концепты дизайна для доступа к моей базе данных? Потому что вы считаете, что SQL не слишком причудливый (или новый)? Или вам это не нравится? Просто потому, что что-то не соответствует модели, которую вы чувствуете наиболее комфортно, не означает, что это плохо или неправильно. Это означает, что он отличается и, вероятно, отличается по законной причине. Вы используете другой инструмент для другой задачи.

Ответ 3

Вы должны посмотреть на статью "Out of the Tar Pit" Бена Мозли и Питера Маркса, доступных здесь: "Из ямы Тар" (6 февраля 2006 г.)

Это современная классика, в которой подробно описывается парадигма программирования/система, называемая функционально-реляционным программированием. Хотя он напрямую не связан с базами данных, в нем обсуждается, как изолировать взаимодействия с внешним миром (например, базы данных) от функционального ядра системы.

В документе также обсуждается, как реализовать систему, в которой внутреннее состояние приложения определяется и модифицируется с использованием реляционной алгебры, которая, очевидно, связана с реляционными базами данных.

В этой статье не дается точный ответ на вопрос о том, как интегрировать базы данных и функциональное программирование, но это поможет вам разработать систему для минимизации проблемы.

Ответ 4

• Функциональные языки не имеют цели оставаться без гражданства, у них есть цель сделать управление явным государством. Например, в Haskell вы можете рассматривать государственную монаду как сердце "нормального" состояния, а МО-монаду - представление состояния, которое должно существовать вне программы. Обе эти монады позволяют вам (a) явно представлять действия с состоянием и (b) создавать действия с состоянием, составляя их с использованием ссылочно прозрачных инструментов.

• Вы ссылаетесь на количество ORM, которые по их имени абстрактно базируются как наборы объектов. По правде говоря, это не то, что представляет собой информация в реляционной базе данных! По его имени он представляет реляционные данные. SQL - это алгебра (язык) для обработки отношений в реляционном наборе данных и фактически является "самой функциональной". Я объясняю это тем, что (а) ORM не являются единственным способом сопоставления данных базы данных, (б) что SQL на самом деле является довольно приятным языком для некоторых проектов баз данных и (c) что функциональные языки часто имеют реляционную алгебру сопоставления, которые выставляют силу SQL в идиоматическом (и в случае Haskell, typechecked) образом.

Я бы сказал, что большинство lisps - плохой человек, функциональный язык. Он полностью способен использоваться в соответствии с современными функциональными практиками, но поскольку он не требует их, сообщество с меньшей вероятностью будет использовать их. Это приводит к сочетанию методов, которые могут быть очень полезными, но, безусловно, скрывает, насколько чистые функциональные интерфейсы могут по-прежнему использовать базы данных.

Ответ 5

Я не думаю, что состояние языков fp без гражданства является проблемой при подключении к базам данных. Lisp - не чистый язык программирования, поэтому у него не должно быть проблем с состоянием. И чистые языки функционального программирования, такие как Haskell, имеют способы работы с вводом и выводом, которые могут быть применены к использованию баз данных.

С вашего вопроса кажется, что ваша главная проблема заключается в поиске хорошего способа абстрагировать данные на основе записей, которые вы возвращаете из своей базы данных, в нечто, что lisp -y (lisp -ish?) без нужно написать много кода SQL. Это больше похоже на проблему с инструментами/библиотеками, чем с проблемой языковой парадигмы. Если вы хотите сделать чистый FP, возможно, Lisp не подходит для вас. Общий Lisp больше связан с интеграцией хороших идей из оо, fp и других парадигм, чем с чистым fp. Возможно, вам следует использовать Erlang или Haskell, если вы хотите пройти чистый маршрут FP.

Я думаю, что идеи "псевдо-оо" в Lisp тоже имеют свои достоинства. Вы можете попробовать их. Если они не соответствуют тому, как вы хотите работать с вашими данными, вы можете попробовать создать слой поверх Weblocks, который позволит вам работать с вашими данными так, как вы хотите. Это может быть проще, чем писать все сами.

Отказ от ответственности: я не эксперт Lisp. Я в основном интересуюсь языками программирования и играл с Lisp/CLOS, Scheme, Erlang, Python и немного Ruby. В повседневной жизни программирования я все еще вынужден использовать С#.

Ответ 6

Если ваша база данных не уничтожает информацию, вы можете работать с ней функциональным образом, совместимым с "чисто функциональными" значениями программирования, работая с функциями всей базы данных как значения.

Если в момент времени T база данных гласит, что "Боб любит Сьюзи", и у вас была функция like, которая приняла базу данных и аналог, тогда, пока вы можете восстановить базу данных в момент T, у вас есть чисто функциональная программа, которая включает базу данных, например

# Start: Time T
likes(db, "Bob")
=> "Suzie"
# Change who bob likes
...
likes(db "Bob")
=> "Alice"
# Recover the database from T
db = getDb(T)
likes(db, "Bob")
=> "Suzie"

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

Это главная идея Datomic, например.

Ответ 7

Совсем нет. Существует жанр баз данных, известный как "Функциональные базы данных", из которых Mnesia, пожалуй, самый доступный пример. Основной принцип заключается в том, что функциональное программирование является декларативным, поэтому его можно оптимизировать. Вы можете реализовать объединение, используя List Comprehensions в постоянных коллекциях, а оптимизатор запросов может автоматически разработать, как реализовать доступ к диску.

Mnesia написана в Erlang и существует хотя бы одна веб-фреймворк (Erlyweb) для этой платформы. Erlang по своей сути параллелен модели с нисходящей нитью с общим доступом, поэтому определенным образом он поддается масштабируемым архитектурам.

Ответ 8

Мне больше всего нравится Haskell. Самая известная веб-инфраструктура Haskell (сопоставимая с Rails и Django) называется Yesod. Кажется, у него довольно классный, безопасный по типу, многопроцессорный ORM. Взгляните на главу Persistance в своей книге.

Ответ 9

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

Идея объектно-реляционного Mapper, в которой вы импортируете запись базы данных в качестве объекта и затем модифицируете ее, применима и полезна для функционального программирования, как и для объектно-ориентированного программирования. Одно из предостережений заключается в том, что функциональное программирование не изменяет объект на месте, но API базы данных может позволить вам изменить запись на месте. Управляющий поток вашего клиента будет выглядеть примерно так:

• Импортировать запись в качестве объекта (API базы данных может заблокировать запись в данный момент),
• Прочитайте объект и ветвь на основе их содержимого, как вам нравится,
• Пакет нового объекта с вашими желаемыми изменениями
• Передайте новый объект соответствующему вызову API, который обновляет запись в базе данных.

В базе данных будет обновлена ​​запись с вашими изменениями. Чистое функциональное программирование может запретить переназначение переменных в рамках вашей программы, но ваш API базы данных все еще может разрешать обновления на месте.

Ответ 10

Базы данных и функциональное программирование могут быть объединены.

например:

Clojure - это функциональный язык программирования, основанный на теории реляционных баз данных.

               Clojure -> DBMS, Super Foxpro
                   STM -> Transaction，MVCC
Persistent Collections -> db, table, col
              hash-map -> indexed data
                 Watch -> trigger, log
                  Spec -> constraint
              Core API -> SQL, Built-in function
              function -> Stored Procedure
             Meta Data -> System Table

Примечание: в последней спецификации spec2 спецификация больше похожа на RMDB. смотрите: spec-alpha2 wiki: Schema-and-select

Я выступаю за: построение реляционной модели данных поверх хэш-карты для достижения сочетания преимуществ NoSQL и RMDB. На самом деле это обратная реализация posgtresql.

Печатание утки: Если это похоже на утку и крякает как утка, это должна быть утка.

Если модель данных clojure, такая как RMDB, средства закрытия, такие как RMDB, и манипулирование данными clojure, такие как RMDB, clojure должен быть RMDB.

Clojure - это функциональный язык программирования, основанный на теории реляционных баз данных.

Все RMDB

Реализация реляционной модели данных и программирования на основе хэш-карты (NoSQL)