[OT] SQL, stored procedures, triggers & co

Community IT
1

Che ne pensate di questo? Simplify: move code into database functions | Derek Sivers

Di recente mi sono semplificato parecchio la vita usando viste e
almeno una funzione nel database, che tengo versionate tra i miei
models e refresho quando necessario in automatico.
Finora tutto bene.

Il punto pi sensato delle obiezioni nei commenti il fatto di avere
poi il sistema troppo CPU bound sul versante database. Il web layer si
scala bene, il db insomma, anche se utlimamente mi sto interessando
molto a pg_shard di citusdb che sembra promettente.

-f

2

La mia personale risposta qui:

Andrea

3

Personalmente ritengo che tutto ciò che ha elencato in “Why that’s bad”
sia
del tutto assurdo.

Quando ho letto:

  • If it’s ever advantageous to switch languages (say from Ruby to
    JavaScript, or Python to Elixir), you’re going to have to re-write
    absolutely everything.

stava per prendermi un infarto.

Alessandro R.

On Mon, May 4, 2015 at 3:17 PM, Andrea D.
[email protected]

4

Che poi, usare un linguaggio diverso da quello del db layer è un
vantaggio
perché hai scelta.

5

Sivers dà consigli a tutti, ma è un musicista che ha avuto una buona
idea di business. E` passato da PHP a Rails a PHP… devo aggiungere
altro?

Concordo con Alessandro :slight_smile:

Condivido le idee di Rich Hickey, ma credo che Sivers non ci abbia
capito molto in quello che dice, almeno posso dire che abbia ‘piegato’,
troppo, le idee di Rich per sostenere le sue idee.

SQL è un DSL di sucesso, forse il più famoso. Usare triggers, viste e
quant’altro può aumentare le prestazioni e consente di usare framework
leggeri. Ultimamente mi sto avvicinando ad altri linguaggi come Haskell,
Clojure e Lisp. Uno dei valori della comunitadi lisp e la semplicita`
e Rich con il suo Clojure ha ereditato quei valori. Se usi Clojure
invece di complicarti la vita con OOP, usi il data abstraction. Data as
first citizen.

Comunque mettere la logica nel DB è sempre un problema: hai due posti da
studiare per capire cosa un programma fa. Una vista non crea nessun
problema, IMHO, visto che può essere trattata come una tabella e con le
materialised views non ci son problemi di prestazione. Metter stored
procedures è tutt’altra cosa, io lo eviterei a meno che non si abbia
problemi grossi di prestazioni non risolvibili in altri modi.

Di solito la verità sta nel mezzo :slight_smile:

6

Il problema principale secondo me è che cominci a mettere della logica
nel database poi devi fare uno sforzo per capire cosa mettere nel
database e cosa no.
Sicuramente usare un linguaggio a oggetti (o comunque un linguaggio
più evoluto) per risolvere gli aspetti più complessi della tua
applicazione è qualcosa di imprescindibile.

Da considerare però che:
“You can win big with server side functions when you prevent
additional round-trips to the database server from your application.
Have the server execute as much as possible at once and only return a
well defined result.” -

Da considerare che usando i test puoi coprire anche la correttezza di
viste, trigger e delle funzioni. Quindi puoi usare Rails per
prepararti delle funzioni nel database e testarne il risulato con
rspec.

On Thu, May 7, 2015 at 7:13 AM, maurizio de magnis

7

No ma…prendiamoli uno per uno:

“Everything must go through these Ruby/Python/PHP/JavaScript classes —
including shell scripts and other things not part of this website.”

Perchè dovrebbe essere una cosa negativa? Non si sa…

“Nothing else may access the database directly, since doing so may break
the rules defined by these surrounding classes.”

Nient’altro deve accedere al DB. esatto. il DB devi far conto che non
esista. Se un altra app deve “dialogare” con la prima userà delle API.

“The database is treated as dumb storage, even though the database is
smart
enough to have most of this logic built-in.”
Il fatto che possa farlo non significa che bisogna usarlo in quella
maniera. Il DB è un posto dove buttare dati e basta…e questa cosa è
magnifica per il principio di “separation of concerns”.

“But if you add business rules into the database itself, it’s now
duplicated, requiring changing in multiple places if the rules change.”
Infatti non lo devi fare!!

“These two systems — the database and its surrounding code — are coupled
and dependent on eachother.”
Cosa??!? Questa affermazione non ha assolutamente alcun senso logico.

“If it’s ever advantageous to switch languages (say from Ruby to
JavaScript, or Python to Elixir), you’re going to have to re-write
absolutely everything.”
e qui mi sono già espresso

Per non parlare della difficoltà nella mantenibilità del sistema,
versioning, debugging, logging, testing, ecc, ecc, ecc…

Alessandro R.

2015-05-07 12:34 GMT+02:00 Riccardo T. [email protected]:

8

Mi è capitato di scrivere stored procedure e chiamarle da Rails o da
altri framework e linguaggi. Test e versioning si possono fare nel
solito modo, sempre sw è. Tra l’altro con PostgreSQL si possono
scegliere vari
linguaggi per scrivere il sw da far girare dentro il DB tra cui anche
Ruby PostgreSQL: Documentation: 9.4: Procedural Languages
GitHub - Absolight/postgresql-plruby: PL/Ruby procedural language for the PostgreSQL database system by Guy Decoux

Muovere pochi dati tra DB e application server alle volte può rendere
fattibili elaborazioni che altrimenti sarebbero state proibitive.
Proprio questo pomeriggio pensavo di farlo di nuovo ad anni di distanza
(succede di rado). Mi limiterei però a pochissime procedure, lo stretto
indispensabile e quando non se ne può fare a meno.

A proposito, se la vostra applicazione Rails non dovesse essere l’unico
client del DB, considerate di usare i constraint CHECK per mettere delle
validazioni anche nel DB. MySQL le ignora, gli altri DB di solito no.
Siamo abituati a diversi layer di protezione dati: JavaScript nei form,
validate nei modelli, perché non anche nel DB?

Paolo