J'envisage de développer une application multiclients (web,windows,linux
...) sur un moteur FireBird.
Je me posait la question de l'opportunité de centraliser les traitements
au niveau du serveur: accès aux données via des view et traitements via
procédures stockées, dans le but de ne gérer que l'affichage/saisie au
niveau des clients.
Avez vous des expériences similaires ? Quels sont les avantages, les
inconvénients, les défauts en terme de programmation, de maintenance, etc
???
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Igor Racic
jpaulin wrote:
Bonjour,
J'envisage de développer une application multiclients (web,windows,linux ...) sur un moteur FireBird.
Je me posait la question de l'opportunité de centraliser les traitements au niveau du serveur: accès aux données via des view et traitements via procédures stockées, dans le but de ne gérer que l'affichage/saisie au niveau des clients.
Avez vous des expériences similaires ? Quels sont les avantages, les inconvénients, les défauts en terme de programmation, de maintenance, etc ???
Merci d'avance pour vos retours d'expérience.
gg
Je ne connais pas FireBird, mais si ta base a des "features" que tu a besoin, laisse le faire ça. Si non, tu doit te occuper comment faire les jointures, implementaire system de securité, si tu change le client tu doit re-écrire tous a nouveau, problème de deployement. Pense aux problèmes de multi accès. Pense à changement dans code qui est bien chère. Pense aux allers-retours pour chanque SQL, les resultats (les lignes, peut être 1000 lignes, peut être plus qui sort et entre pour plusieurs actions (plus de données, plus pire) dans base, performance de compilation des SQL chaque fois, l'utilisation des choses avancé dans la base etc etc...
Le seul inconvenient est que après ça tu est bien "attache" à ta base et pour migrer a une autre, il te faut reécrire le code a nouveau. Tu perd "database independence".
Voilà
Igor
jpaulin wrote:
Bonjour,
J'envisage de développer une application multiclients (web,windows,linux
...) sur un moteur FireBird.
Je me posait la question de l'opportunité de centraliser les traitements
au niveau du serveur: accès aux données via des view et traitements via
procédures stockées, dans le but de ne gérer que l'affichage/saisie au
niveau des clients.
Avez vous des expériences similaires ? Quels sont les avantages, les
inconvénients, les défauts en terme de programmation, de maintenance, etc
???
Merci d'avance pour vos retours d'expérience.
gg
Je ne connais pas FireBird, mais si ta base a des "features" que tu a
besoin, laisse le faire ça.
Si non, tu doit te occuper comment faire les jointures, implementaire
system de securité, si tu change le client tu doit re-écrire tous a
nouveau, problème de deployement. Pense aux problèmes de multi accès.
Pense à changement dans code qui est bien chère. Pense aux
allers-retours pour chanque SQL, les resultats (les lignes, peut être
1000 lignes, peut être plus qui sort et entre pour plusieurs actions
(plus de données, plus pire) dans base, performance de compilation des
SQL chaque fois, l'utilisation des choses avancé dans la base etc etc...
Le seul inconvenient est que après ça tu est bien "attache" à ta base et
pour migrer a une autre, il te faut reécrire le code a nouveau.
Tu perd "database independence".
J'envisage de développer une application multiclients (web,windows,linux ...) sur un moteur FireBird.
Je me posait la question de l'opportunité de centraliser les traitements au niveau du serveur: accès aux données via des view et traitements via procédures stockées, dans le but de ne gérer que l'affichage/saisie au niveau des clients.
Avez vous des expériences similaires ? Quels sont les avantages, les inconvénients, les défauts en terme de programmation, de maintenance, etc ???
Merci d'avance pour vos retours d'expérience.
gg
Je ne connais pas FireBird, mais si ta base a des "features" que tu a besoin, laisse le faire ça. Si non, tu doit te occuper comment faire les jointures, implementaire system de securité, si tu change le client tu doit re-écrire tous a nouveau, problème de deployement. Pense aux problèmes de multi accès. Pense à changement dans code qui est bien chère. Pense aux allers-retours pour chanque SQL, les resultats (les lignes, peut être 1000 lignes, peut être plus qui sort et entre pour plusieurs actions (plus de données, plus pire) dans base, performance de compilation des SQL chaque fois, l'utilisation des choses avancé dans la base etc etc...
Le seul inconvenient est que après ça tu est bien "attache" à ta base et pour migrer a une autre, il te faut reécrire le code a nouveau. Tu perd "database independence".
