Ce que je veux dire (puis j'arrête...) c'est que tu ne peux pas mettre dos à dos les SGBD en disant :
- on s'en fout il y a les ejb ou autre
Ton exemple avec "tx.commit()" est limite comique. Si le SGDB en-dessous n'a pas de support de transaction, ton "tx.commit()" ne sert à rien (et ne fait sûrement rien :-) comme c'est le cas avec beaucoup de wrapper... ). Ou alors il faut vérrouiller toutes les tables (ou quelques tables "judicieusement choisies" (comprendre qu'un jour tu vas oublier de verrouiller une table ou que tu en verrouille une de trop)) et c'est une catastrophe pour la montée en charge, etc.
Pour les réservations de place d'avion ou train, tu ne peux pas faire ça sans un solide système transactionnel (ejb ou pas). Les ejb ne font pas de transactionnel, ne sont pas des serveurs qui supporte plusieurs requête en parallèle et doivent gérer le conflit, etc... Le transactionnel doit être fait au coeur du serveur de base de donnée (il n'y a pas le chois). C'est la même chose pour les contraintes si tu ne veux pas que tes backups soit pollués (parfois même à 3 heures du matin une base est utilisée...).
L'abstraction c'est bien. Mais une bonne base de donnée c'est bien aussi et c'est même parfois indispensable (que l'API de l'abstraction de donnée soit super élégante ou non).
btw : j'en profite pour dire que de faire une base de donnée solide (avec les bonnes contraintes, les controles d'intégrité, les mises à jours de données automatiques des données annexes, etc) c'est très dure.
Mais que c'est profidable après. L'utilisateur final peut utilise psql ou MS-Access, ou faire un script php, il n'y aura pas de problème côté donnée.
[^] # Re: Et mysql
Posté par Ayrton . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
- on s'en fout il y a les ejb ou autre
Ton exemple avec "tx.commit()" est limite comique. Si le SGDB en-dessous n'a pas de support de transaction, ton "tx.commit()" ne sert à rien (et ne fait sûrement rien :-) comme c'est le cas avec beaucoup de wrapper... ). Ou alors il faut vérrouiller toutes les tables (ou quelques tables "judicieusement choisies" (comprendre qu'un jour tu vas oublier de verrouiller une table ou que tu en verrouille une de trop)) et c'est une catastrophe pour la montée en charge, etc.
Pour les réservations de place d'avion ou train, tu ne peux pas faire ça sans un solide système transactionnel (ejb ou pas). Les ejb ne font pas de transactionnel, ne sont pas des serveurs qui supporte plusieurs requête en parallèle et doivent gérer le conflit, etc... Le transactionnel doit être fait au coeur du serveur de base de donnée (il n'y a pas le chois). C'est la même chose pour les contraintes si tu ne veux pas que tes backups soit pollués (parfois même à 3 heures du matin une base est utilisée...).
L'abstraction c'est bien. Mais une bonne base de donnée c'est bien aussi et c'est même parfois indispensable (que l'API de l'abstraction de donnée soit super élégante ou non).
btw : j'en profite pour dire que de faire une base de donnée solide (avec les bonnes contraintes, les controles d'intégrité, les mises à jours de données automatiques des données annexes, etc) c'est très dure.
Mais que c'est profidable après. L'utilisateur final peut utilise psql ou MS-Access, ou faire un script php, il n'y aura pas de problème côté donnée.