c'est déjà le moteur qui connait l'information pertinente
oui, c'est le principe de subsidiarité souvent promu par un architecte applicatif ou un urbaniste :-)
Le choix de se lier à une base de données plutôt qu'une autre est très dépendant de ce type de choix, ça gêne les migrations d'un point de vue architecture technique.
Une base de données est plutôt vue pour stocker des données, pas faire des traitements dessus :-) nous sommes bien d'accord.
Bref, c'est la position d'un DBA de traiter la donnée au plus près de la donnée, un développeur d'application préférera avoir les traitements métier dans son application :-) (et c'est une pratique plus pérenne : 1 seul interlocuteur, 1 seule compétence, moins performant potentiellement mais tellement plus pratique).
donc bon, ça dépend des points de vue, même si j'ai plus confiance dans la pérennité de PostgreSQL que d'Oracle SGBD.
[^] # Re: Utilisation
Posté par BAud (site web personnel) . En réponse au journal Sortie de "The Art of PostgreSQL" de Dimitri Fontaine. Évalué à 3.
oui, c'est le principe de subsidiarité souvent promu par un architecte applicatif ou un urbaniste :-)
Le choix de se lier à une base de données plutôt qu'une autre est très dépendant de ce type de choix, ça gêne les migrations d'un point de vue architecture technique.
Une base de données est plutôt vue pour stocker des données, pas faire des traitements dessus :-) nous sommes bien d'accord.
Bref, c'est la position d'un DBA de traiter la donnée au plus près de la donnée, un développeur d'application préférera avoir les traitements métier dans son application :-) (et c'est une pratique plus pérenne : 1 seul interlocuteur, 1 seule compétence, moins performant potentiellement mais tellement plus pratique).
donc bon, ça dépend des points de vue, même si j'ai plus confiance dans la pérennité de PostgreSQL que d'Oracle SGBD.