Discussion :

[Rayek]

Tu ne sais pas à côté de quoi tu passes ...

Je sais très bien à quoi m'attendre avec Paradox, vu que j'ai fait quelques applications avec.
Mais je préfère de loin travailler avec des bases de données du Style de MySQL, SQL serveur,FireBird qui sont beaucoup plus évoluées et plus fiables que du Paradox.

[ALWEBER]

Je maitrise aussi très bien SQL Server et les fonctions rendues par ces outils ne sont pas les mêmes qu'avec Paradox.
Disons pour simplifier qu'avec une architecture client/serveur on déporte le travail sur le serveur, Avec des object ADO on déporte une partie du travail dans la mémoire de l'ordi. Client et avec Paradox on déporte une partie du travail sur la mémoire de masse de l'ordi Client. Et un ajustement fin de l'ensemble permet d'obtenir de très bon résultat.
D'autre part l'ensemble est peu sensible aux évolutions des constructeurs.

Disons aussi que l'approche Paradox+Delphi est une approche Informatique Industrielle. L'approche Client/serveur est une approche Informatique de gestion héritée des mainFrames. Et nous avons là affaire à deux catégories d'informaticiens qui souvent se comprennent peu.

[ShaiLeTroll]

Un BDE utilisant une Base Paradox, bien configuré, ça peut-être très impressionnant, c'est simplement qu'il faut bien définir le répertoire réseau et le répertoire de travail en local ... j'ai aussi fait des applications avec Paradox, j'ai pleuré par manque de connaissance de ces petits détails, je devrais avoir à tout moment 20 clients sur la base, plus un serveur de tri, lui travaillant en local.

Le serveur de tri modifiait/ajoutait toutes les 50ms un enregistrement dans 5 tables, et les clients devaient eux accéder à une ou deux de ces tables en même temps, et bien, ça ramait sévère, je suis passé sur FB, et bien tout est devenu lent (j'utilisais toujorus des TQuery, les TIBQuery m'ayant posé des soucis)
J'ai reconstitué cette situation, et j'ai modifié le NetFileDir/PrivateDir de la session ... et oh miracle, c'était devenu rapide ... car il n'était plus obligé d'interroger les différents fichiers de lock en local chez chaque client ...
J'ai aussi trouvé les astuces pour que FB soit rapide,
Je pense que c'est pour toutes bases, il faut trouver les astuces ... et parfois certains systèmes sont configurés intelligement de base ...

[Rayek]

Disons pour simplifier qu'avec une architecture client/serveur on déporte le travail sur le serveur, Avec des object ADO on déporte une partie du travail dans la mémoire de l'ordi. Client et avec Paradox on déporte une partie du travail sur la mémoire de masse de l'ordi Client. Et un ajustement fin de l'ensemble permet d'obtenir de très bon résultat.
D'autre part l'ensemble est peu sensible aux évolutions des constructeurs.

http://sql.developpez.com/sgbdr/

Disons aussi que l'approche Paradox+Delphi est une approche Informatique Industrielle. L'approche Client/serveur est une approche Informatique de gestion héritée des mainFrames. Et nous avons là affaire à deux catégories d'informaticiens qui souvent se comprennent peu.

D'où sors tu que Delphi + Paradox = Informatique industrielle ?
J'ai bossé avec pas mal de société industrielle et je peux te dire qu'il ne tourne pas avec du Paradox. C'est du SQL serveur, Oracle ou DB2 minimum.

Rien que le fait que Paradox ne gère pas les Accès concurentiels le rend peu fiable surtout pour de l'industriel.
Imagine la numérotation automatique de code à barres sur une chaine de production. Si deux appels se font en même temps sur la base de données, sans accès concurentiel, tu peux avoir 2 produits différents avec le même numéro.

De plus, tous les problèmes de perte de clef (voir sur le forum) et autres (toujours voir sur le forum), je déconseille fortement l'utilisation de Paradox en client/serveur.

[ShaiLeTroll]

D'où sors tu que Delphi + Paradox = Informatique industrielle ?

Oui, ALWEBER, c'est un peu un raccourci, mais personnellement, j'ai fait deux projets de pilotage de trieuse industrielle, et c'était en paradox car c'est des applications locales, la durée de vie des données est entre la milli-secondes et 24h ...

Perso, les vrais indus avec lesquels j'ai travaillé, avait toujours un système de données séparées pour les données persistantes et les données volatiles, le premier souvent en Oracle (ultra alégé pour une utilisation locale avec toad), et le second, un système de dumping mémoire en temps réel (pour une partie des données volatiles dont la durée de vie excède un certain délai)

Rien que le fait que Paradox ne gère pas les Accès concurentiels le rend peu fiable surtout pour de l'industriel.

tu abuses un peu quand même, je n'ai jamais eu de doublon avec les auto-inc par exemple
Et pour la numérotation automatique de code à barres, si il n'est pas géré par un trigger (oracle, ...) en paradox, tu le gère via un compteur, et il est vrai, il faut gérer ses propres locks ... mais quand tu fais de l'industriel, tu dois connaitre ton outil, et agir en conséquence ... mais bon, je suis d'accord, ORACLE ou O2 (Orsay Object pour initié) reste les références pour les DB industriels tel que pour les robots de chaine de montage de Renault par exemple ... le tout bien sur allié à du C, Pro*C ou O2C ...

Par contre, la perte partielle ou complète du ficheir d'index, c'est vrai que ... avec un de mes programmes, c'est simple, après 8h d'utilisation non stop (server de tri oblige) avec 50 000 articles triés ça fait près d'un 200 000 insertion dans 4 tables, 150 000 delete, 1 million d'update sur une pauvre base paradox en 8h (je ne connais pas bcp de programmes qui font autant de volume, les applis que je maintien en ce moment, ça doit leur prendre 1 mois pour le même volume) ... un jour, le client n'a pas respecté une consigne, de redémarrer l'ordi (on leur avait proposé un système de reboot auto lorsque la machine avait plus de 9minutes d'arret, il l'ont refusé), donc ils ont laissé tourné le programme plus de 72h, donc 3*8h, eh bien ce fut le crash durant le 4eme 8h, ... index mort ... heureusement, le tri du matin n'avait qu'à peine commencer ...

[ALWEBER]

Malatar a écrit :
D'où sors tu que Delphi + Paradox = Informatique industrielle ?

Tout simplement par les développements réalisés et les formations que j'ai pu animer sur Delphi, SQL Server et Paradox entre 1994 et 2007 ou les présentations que j'ai réalisé pour les conférences Borland depuis 1997.

A titre d'exemple : Les deux nouvelles attractions Euro Disney mis en place par les américains cette année sont réalisés avec ces outils.

[SergioMaster]

Je ne croyais pas , par ce post tout bête , alimenter une telle polémique
m'enfin pourvu que ça serve

[Sunchaser]

Je ne croyais pas , par ce post tout bête , alimenter une telle polémique
m'enfin pourvu que ça serve

Effectivement SergioMaster, et merci finalement (a tous) ... les points et les différents avis exposés sont extremement intéressants ...

[Rayek]

A titre d'exemple : Les deux nouvelles attractions Euro Disney mis en place par les américains cette année sont réalisés avec ces outils.

Je voudrais bien voir ca. Tu as un article qui en parle ?

[ALWEBER]

A l'attention de Malatar - Euro Disney.
J'ai été impliqué à titre professionnel dans ces projets au début de cette année.

[Rayek]

A l'attention de Malatar - Euro Disney.
J'ai été impliqué à titre professionnel dans ces projets au début de cette année.

Faudrat que tu m'epliques en quoi est nécessaire une base de données pour une attraction ? Les entrées réalisées sur chacune ? autres ?

[ALWEBER]

Les bases de données sont chargées entre autres par des relevés de mesure. Les bases sont soumises ensuite à des requêtes comme n'importe quelle autre système de base de données. On a donc un système classique de base de données en réseau multi-utilisateurs, multi-tables. Les concepteurs américains de ces attractions sont à l'origine de ces choix. Les décisions des américains, on le sait, sont généralement plus pragmatiques qu'idéologiques.

[Rayek]

Les bases de données sont chargées entre autres par des relevés de mesure. Les bases sont soumises ensuite à des requêtes comme n'importe quelle autre système de base de données. On a donc un système classique de base de données en réseau multi-utilisateurs, multi-tables. Les concepteurs américains de ces attractions sont à l'origine de ces choix. Les décisions des américains, on le sait, sont généralement plus pragmatiques qu'idéologiques.

Quels sont les dialogues effectués sur la base de données , car si c'est des insert de l'attraction et des requetes Select pour les utilisateurs, c'est pas du client/serveur haut de game ca, aucun risque et une petite base de données comme paradox suffit.

Tu abuses un peu quand même, je n'ai jamais eu de doublon avec les auto-inc par exemple
Et pour la numérotation automatique de code à barres, si il n'est pas géré par un trigger (oracle, ...) en paradox, tu le gère via un compteur, et il est vrai, il faut gérer ses propres locks ... mais quand tu fais de l'industriel, tu dois connaitre ton outil, et agir en conséquence ... mais bon, je suis d'accord, ORACLE ou O2 (Orsay Object pour initié) reste les références pour les DB industriels tel que pour les robots de chaine de montage de Renault par exemple ... le tout bien sur allié à du C, Pro*C ou O2C ...

Tes applications font elles des updates et Select sur un même enregistrement, si non, normal que tu n'es pas le problème.
Dès que tu as risque de travail sur un même enregistrement de plusieurs applications, il faut impératiement gérer par une transaction, sinon, tu es bon pour des erreus de calculs et autres dans les résultat finaux.

Par contre, la perte partielle ou complète du ficheir d'index, c'est vrai que ... avec un de mes programmes, c'est simple, après 8h d'utilisation non stop (server de tri oblige) avec 50 000 articles triés ça fait près d'un 200 000 insertion dans 4 tables, 150 000 delete, 1 million d'update sur une pauvre base paradox en 8h (je ne connais pas bcp de programmes qui font autant de volume, les applis que je maintien en ce moment, ça doit leur prendre 1 mois pour le même volume) ... un jour, le client n'a pas respecté une consigne, de redémarrer l'ordi (on leur avait proposé un système de reboot auto lorsque la machine avait plus de 9minutes d'arret, il l'ont refusé), donc ils ont laissé tourné le programme plus de 72h, donc 3*8h, eh bien ce fut le crash durant le 4eme 8h, ... index mort ... heureusement, le tri du matin n'avait qu'à peine commencer ...

Rien que le fait que des problèmes d'index avec redémarrage nécessaire du PC me dis que c'est pas très fiable cela.
Une application doit pouvoir tourner 24h/24 7j/7 sans avoir besoin de faire un redémarrage chaque jour.

Pour ma part j'ai 3 applications Client/Serveur qui tournent non stop et je peux te dire qu'avec du paradox ca aurait été impossible vu le nombre de requete/update/select/insert qu'il y a.
En plus devoir redemarrer le PC, toutes les 8h serait impossible
Mis a part la derniere application que je modifie, les 2 autres ca fait plus de 8 mois que je ne les ai pas redémarrer et elles en font des choses : Requetes SQL diverses, envoi de requete Http, envoi de mails, Dialogues avec les banques selon divers moyens fournit (DLL, HTTPS, etc ...)

PS: Depuis quand 3*8h ca fait 72h

[ALWEBER]

Je comprend que les échecs que tu as pu ressentir en voyant une table paradox briser ses index de rage de voir son développeur ayant mélangé ses langages de table ou ayant structuré son modèle relationnel sans faire appel aux formes normales.

Aujourd'hui on dépasse facilement le million d'enregistrement sur une table Paradox tout simplement parce que le matériel est beaucoup plus rapide qu'auparavant et que Microsoft a fiabilisé ses systèmes d'exploitation et maitrise mieux le protocole TCP/IP. (Paradox a été conçu à un moment ou windows tournait dans un réseau avec le protocole NetBEUI). J'ai le souvenir en 1993 ou pour faire une requête sur 350 000 enregistrement il fallait découper la table en trois parties. J'ai le souvenir aussi que à la fin des années 90 les mortels verrous (Dead-Lock) sur SQL Server étaient monnaie courante.

Donc pour paraphraser Darwin et son évolution des espèces deux choses sont importantes l'objet et l'environnement. Ce que tu dis était vrai il y a quelques années ce ne l'est plus aujourd'hui tout simplement parceque si Paradox n'a pas évolué, l'environnement lui a évolué.

Effectivement la notion de transaction est importante dans le respect des règle ACID et Paradox n'implémente pas cette fonctionnalité mais sache que les applications que nous développons que ce soit en SQL Serveur ou en Paradox ( ce sont avec Delphi nos spécialités) marchent correctement (heureusement pour nos clients dont certains sont des banques) .

Bon je te laisse pour le Week End!

A la semaine prochaine !

PS : J'avais cru voir modérateur dans ton profil ....

[aityahia]

je vois que le post va vers la dérive, ALWEBER est un issu de l'ancienne école est un fervent protecteur de paradox et malatar de la nouvel alors sera difficile d'arrivé a un accord vu les divergences des points de vue,personnellement je partage celui de malatar.

[SergioMaster]

Loin de vouloir alimenter la polémique voici quand même quelques résultats sur des tests 'simples'

objet : détruire une table, la créer et la remplir (5000 enrg)
PS : je vous fait grâce du traitement qui rempli la table puisque de toute facon il est identique quelque soit la méthode


avec ACCESS+ADO 18s
avec PARADOX+BDE 1 à 2s
PARADOX+ADO non testé (pour l'instant on verra apres les vacances)



l'inconvénient de BDE il faut l'installer : d'accord mais 5mn d'install sur un poste me parait peut en comparaison des résultats.
il n'est plus maintenu : mais il est éprouvé et il fonctionne encore sous VISTA


inconvénient d'ACCESS effectivement @aityahia a raison il faut souvent compresser la base
remarque supplémentaire
[D2006+ACCESS+RAVE] problème d'acces aux Memos (TWideMemo)

Ancienne école

surement vu mon age canonique mais bon les resultats sont là

[aityahia]

remarque supplémentaire
[D2006+ACCESS+RAVE] problème d'acces aux Memos (TWideMemo)

ça je viens de l'apprendre merci.

[Rayek]

avec ACCESS+ADO 18s
avec PARADOX+BDE 1 à 2s
PARADOX+ADO non testé (pour l'instant on verra apres les vacances)

Tu peux faire voir le code d'insertion ?
Car avec Paradox et Access tu as des méthodes plus ou moins rapide pour chacun.

PS : J'avais cru voir modérateur dans ton profil ....

Je vois pas ou tu veux en venir ?
Modérateur ne veut pas dire qu'on n'a pas le droit de débattre sur un sujet.

[ALWEBER]

La position que je défend sur ce post est similaire à la position que Aityahia défend actuellement sur un autre post concernant l'avenir de Delphi. Il maitrise Delphi et défend cette position parce qu'il connait des domaines en informatique que son détracteur ne connait pas.

Non ce post ne va pas à la dérive. Ce que je souhaite simplement c'est que la critique soit positive. Qu'en réponse à une question comme celle qui était posée dans ce post on puisse dire : Je te recommande cette solution parce que je sais l'utiliser et que pour moi elle est bien et non le contraire.

Malatar et Aityahia avez une trentaine d'années. J'en ai effectivement vingt de plus. La majorité des interventions que notre équipe fait vis à vis de nos clients ( pratiquement que des grands comptes ou des institutionnels ) vise à fiabiliser des structures de données qui sont montées en puissance. Dans ces développements nous utilisons essentiellement Delphi, Paradox, SQL Server, Oracle et des fusions XML/XSL. La combinaison de ces outils permet des développement très puissants dans le monde des micro-ordinateurs. Nous travaillons maintenant sur des bases de données dont certaines tables comptent plusieurs dizaines de millions d'enregistrement. Nous n'aurions pas pu arriver à ces résultats sans tous ces outils.

[SergioMaster]

Tu peux faire voir le code d'insertion ?
Car avec Paradox et Access tu as des méthodes plus ou moins rapide pour chacun.

grosso-modo

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
for i=1 to n do
  begin
    Table.insert;
    TableCle.asInteger=i;   // autoinc à exclure 
    TableChamp1.asString:='tttttttttttttttttttttt';
    etc ....... pour les autres champs  
    Table.Post;
  end;

je ne pense pas que le code 'sensu stricto', ci dessous ,soit important
puisque j'ai utilisé les mêmes pour le test

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
 
//--- ETIQUETTES MANUELLES ----------------
//-----------------------------------------
MainDataE.Modele.DataSource:=DSPlus;
MainDataE.Article.DataSource:=DSPlus;
MainDataE.Modele.Active:=True;
MainDataE.Article.Active:=True;
with JvMemory1 do
  begin
     try First; except Exit; end;
     while not EOF do
     begin
     n:=JvMemory1Nombre.asInteger;
     for i:=1 to n do
      begin
          if Xn<Ne then while PremierePage(Xn) do Vierge(Xn);
          PDOXTable1.Insert;
          PDOXTable1.FieldByName('NUMERO').asinteger:=Xn;
          PDOXTable1.FieldByName('ARTICLE').asString:=JvMemory1MODELE.asString+'-'+JvMemory1ASSORTIMENT.asString;
          PDOXTable1.FieldByName('POINTURE').asString:=JvMemory1POINTURE.asString;
          PDOXTable1.FieldByName('DESCRIPTION').asString:=MainDataE.ArticleDESCRIPTION.asString;
          if EFormat.ItemIndex in [0,2] then
             begin
               CDB:=MainDataE.Modele.FieldByName('EAN13').asString;
               CDB:=CDB+jvMemory1ASSORTIMENT.asString;
             try
               StrToInt(JvMemory1POINTURE.asString);
               CDB:=CDB+Jvmemory1POINTURE.asString;
             except
               for p:=1 to 24 do
                 if Trim(MainDataE.Modele.FieldbyName('PT_'+intToStr(p)).asString)=Trim(JvMemory1Pointure.asString) then Break;
               CDB:=CDB+Format('%.3d',[p]);
             end;
               if (MainDataE.ArticleTYPE.asString='N')
               OR (MainDataE.ArticleTYPE.asString='T')
               OR (MainDataE.ArticleTYPE.asString='U')
               OR (MainDataE.ArticleTYPE.asString='V')
                 then PDOXTable1.FieldByName('Textile').asString:=MaindataE.Modele.FieldByName('DESCRIPTION').asString;
             PDOXTable1.FieldByName('NOMIMAGE').Clear;
             PDOXTable1.FieldByName('DESSUS').Clear;
           end
        else begin
          CDB:='*'+jvMemory1MODELE.asString+'-'+jvMemory1ASSORTIMENT.asString;
          CDB:=CDB+jvMemory1POINTURE.asString;
          PDOXTable1.FieldByName('NOMIMAGE').asString:=MainDataE.Modele.FieldByName('IMAGE').Value;
           PDOXTable1.FieldByName('DESSUS').asString:=MainDataE.Article.FieldByName('DESSUS').asString;
        end;
        PDOXTable1.FieldByName('CODEBARRE').asString:=CDB;
        PDOXTable1.Post;
        Inc(Xn);
      end;
     Next;
   end; // While
end;

cependant il serait peut-etre interressant de tester avec SQL ('insert ...')


Maintenant reste le problème

[D2006+ACCESS+RAVE] problème d'acces aux Memos (TWideMemo)

qui est un bug connu RAVE+ D2006 et +, puisque un de mes postulats de départ est d'utiliser aussi des champs mémos (la solution CHAR(255) en remplacement fonctionne mais réduit la taille possible
(je m'égare mon avion est pret à décoller