[sql] I database e la programmazione funzionale sono in disaccordo?


3 Answers

Arrivando a questo dal punto di vista di una persona del database, trovo che gli sviluppatori front-end si sforzano troppo per trovare modi per rendere i database adatti al loro modello piuttosto che considerare i modi più efficaci per utilizzare database che non sono orientati agli oggetti o funzionali ma relazionali e insiemistica. Ho visto questo in genere si traduce in codice poco performante. E inoltre crea codice che è difficile da sintonizzare sulle prestazioni.

Quando si considera l'accesso al database ci sono tre considerazioni principali: l'integrità dei dati (perché tutte le regole aziendali dovrebbero essere applicate a livello di database non attraverso l'interfaccia utente), le prestazioni e la sicurezza. SQL è stato scritto per gestire le prime due considerazioni in modo più efficace rispetto a qualsiasi linguaggio front-end. Perché è specificamente progettato per farlo. L'attività di un database è molto diversa dall'attività di un'interfaccia utente. C'è da meravigliarsi se il tipo di codice che è più efficace nella gestione del compito è concettualmente diverso?

E i database contengono informazioni fondamentali per la sopravvivenza di un'azienda. C'è da meravigliarsi se le imprese non sono disposte a sperimentare nuovi metodi quando è in gioco la loro sopravvivenza. Molte aziende non sono nemmeno disposte ad aggiornare a nuove versioni del loro database esistente. Quindi c'è un inerente conservatorismo nella progettazione del database. Ed è deliberatamente in quel modo.

Non proverei a scrivere T-SQL o usare concetti di progettazione di database per creare la tua interfaccia utente, perché dovresti provare a usare il linguaggio dell'interfaccia e i concetti di progettazione per accedere al mio database? Perché pensi che SQL non sia elegante (o nuovo) abbastanza? O non ti senti a tuo agio con esso? Solo perché qualcosa non si adatta al modello con cui ti senti più a tuo agio, non significa che sia sbagliato o sbagliato. Significa che è diverso e probabilmente diverso per una ragione legittima. Si utilizza uno strumento diverso per un'attività diversa.

Question

Sono stato sviluppatore web da qualche tempo e di recente ho iniziato a imparare alcune programmazioni funzionali. Come altri, ho avuto qualche problema significativo ad applicare molti di questi concetti al mio lavoro professionale. Per me, la ragione principale per questo è che vedo un conflitto tra l'obiettivo di FP di rimanere apolidi sembra piuttosto in disaccordo con il fatto che la maggior parte del lavoro di sviluppo web che ho fatto è stato pesantemente legato ai database, che sono molto incentrati sui dati.

Una cosa che mi ha reso uno sviluppatore molto più produttivo sul versante OOP delle cose è stata la scoperta di mapper relazionali object come MyGeneration d00dads per .Net, Class :: DBI per perl, ActiveRecord per ruby, ecc. Questo mi ha permesso di stare lontano dalla scrittura inserire e selezionare le dichiarazioni tutto il giorno e concentrarsi sul lavorare facilmente con i dati come oggetti. Ovviamente, potrei scrivere ancora query SQL quando il loro potere era necessario, ma per il resto è stato estratto in modo piacevole dietro le quinte.

Ora, passando alla programmazione funzionale, sembra che con molti dei framework web FP come i link sia necessario scrivere molto codice SQLl, come in questo esempio . Weblocks sembra un po 'meglio, ma sembra utilizzare una specie di modello OOP per lavorare con i dati, e richiede ancora la scrittura manuale del codice per ogni tabella nel database come in questo esempio . Suppongo che tu usi un po 'di generazione di codice per scrivere queste funzioni di mappatura, ma ciò sembra decisamente non-simile.

(Nota che non ho guardato molto attentamente Weblocks o Links, potrei solo fraintendere il modo in cui vengono utilizzati).

Quindi la domanda è, per le porzioni di accesso al database (che credo siano piuttosto grandi) di applicazioni web, o altri sviluppi che richiedono l'interfaccia con un database SQL ci sembra di essere costretti a scendere uno dei seguenti percorsi:

  1. Non usare la programmazione funzionale
  2. Accedere ai dati in un modo fastidioso e non astratto che implica la scrittura manuale di molti collegamenti a codice di tipo SQL o SQL
  3. Forza il nostro linguaggio funzionale in un paradigma pseudo-OOP, rimuovendo così parte dell'eleganza e della stabilità della vera programmazione funzionale.

Chiaramente, nessuna di queste opzioni sembra ideale. Ha trovato un modo per aggirare questi problemi? C'è davvero un problema anche qui?

Nota: Personalmente ho più familiarità con LISP sul fronte FP, quindi se si vuole dare qualche esempio e conoscere più lingue FP, il lisp sarebbe probabilmente la lingua preferita di scelta

PS: per i problemi specifici di altri aspetti dello sviluppo web vedi questa domanda .




  1. I linguaggi funzionali non hanno l'obiettivo di rimanere apolidi, hanno l'obiettivo di rendere esplicita la gestione dello stato. Ad esempio, in Haskell, puoi considerare la monade di stato come il cuore dello stato "normale" e la monade di IO una rappresentazione di stato che deve esistere al di fuori del programma. Entrambe queste monadi consentono di (a) rappresentare esplicitamente azioni stateful e (b) di costruire azioni stateful componendole usando strumenti referenzialmente trasparenti.

  2. Si fa riferimento a un numero di ORM, che, come per il loro nome, costituiscono database astratti come insiemi di oggetti. Veramente, questo non è ciò che rappresenta l'informazione in un database relazionale! Per suo nome, rappresenta i dati relazionali. SQL è un'algebra (linguaggio) per gestire le relazioni su un set di dati relazionali ed è in realtà abbastanza "funzionale". Lo presento per considerare che (a) gli ORM non sono l'unico modo per mappare le informazioni del database, (b) che SQL è in realtà una lingua piuttosto carina per alcuni progetti di database, e (c) che i linguaggi funzionali hanno spesso l'algebra relazionale mappature che espongono la potenza di SQL in modo idiomatico (e nel caso di Haskell, tipografato).

Direi che molte lisp sono il linguaggio funzionale di un povero. È completamente in grado di essere utilizzato secondo le moderne pratiche funzionali, ma dal momento che non richiede loro la comunità è meno propensa a usarle. Ciò porta a una combinazione di metodi che può essere estremamente utile, ma certamente oscura il modo in cui le interfacce funzionali pure possono ancora utilizzare i database in modo significativo.




Se il tuo database non distrugge le informazioni, puoi lavorarci coerentemente con i valori di programmazione "puramente funzionali" lavorando come funzioni in funzioni dell'intero database.

Se al tempo T il database afferma che "a Bob piacciono Suzie", e che avevi una funzione che accettava un database e un liker, allora fintanto che puoi recuperare il database al tempo T hai un programma funzionale puro che coinvolge un database . per esempio

# 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"

Per fare questo non puoi mai buttare via le informazioni che potresti usare (il che in pratica significa che non puoi buttare via le informazioni), quindi le tue esigenze di archiviazione aumenteranno monotonicamente. Ma puoi iniziare a lavorare con il tuo database come una serie lineare di valori discreti, dove i valori successivi sono correlati ai precedenti attraverso le transazioni.

Questa è l'idea principale alla base di Datomic , per esempio.




Sono più a mio agio con Haskell. Il framework web Haskell più importante (paragonabile a Rails e Django) si chiama Yesod. Sembra avere un ORM multi-backend piuttosto bello, sicuro per il tipo. Dai un'occhiata al capitolo Persistenza nel loro libro.




Related