Forum: Italian Ruby user group [OT] SQL, stored procedures, triggers & co.

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Cb8e3a1650513848561ca38f84399fa1?d=identicon&s=25 Fabrizio Regini (freegenie)
on 2015-05-04 11:17
(Received via mailing list)
Che ne pensate di questo? http://sivers.org/pg

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
B55d9706b57e8d286a4f198daf2ac69c?d=identicon&s=25 Andrea Dallera (edwin_bolthar)
on 2015-05-04 15:17
La mia personale risposta qui:

https://usingimho.wordpress.com/2015/05/04/design-space/

Andrea
32d80da41830a6e6c1bb3eb977537e3e?d=identicon&s=25 Alessandro R. (alessandro_r)
on 2015-05-07 07:04
(Received via mailing list)
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 Rodi

On Mon, May 4, 2015 at 3:17 PM, Andrea Dallera
<andrea@andreadallera.com>
321db48bf4bdf48da05e781325aed20a?d=identicon&s=25 Maurizio De magnis (olistik)
on 2015-05-07 07:16
(Received via mailing list)
Che poi, usare un linguaggio diverso da quello del db layer è un
vantaggio
perché hai scelta.
Cb8e3a1650513848561ca38f84399fa1?d=identicon&s=25 Fabrizio Regini (freegenie)
on 2015-05-07 08:56
(Received via mailing list)
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." -
http://dba.stackexchange.com/questions/8119/postgr...

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
666b4ee5c26c5f60f0448ad0ab7777f3?d=identicon&s=25 Riccardo Tacconi (rtacconi)
on 2015-05-07 12:34
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 :-)

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 comunita` di 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 :-)
32d80da41830a6e6c1bb3eb977537e3e?d=identicon&s=25 Alessandro R. (alessandro_r)
on 2015-05-07 19:02
(Received via mailing list)
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 Rodi

2015-05-07 12:34 GMT+02:00 Riccardo Tacconi <rtacconi@gmail.com>:
7de465f222e6a9c7fe658e370d0bfe05?d=identicon&s=25 Paolo Montrasio (pmontrasio)
on 2015-05-09 00:00
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 http://www.postgresql.org/docs/9.4/static/external-pl.html
https://github.com/Absolight/postgresql-plruby

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
This topic is locked and can not be replied to.