Discussion :

[perrine1985]

Bonjour à tous,

Je suis en plein analyse d'une nouvelle application et je me demande si Windev 17 est le bon outils pour la développer.

Voici ma problèmatique :
Je reçois plusieurs fichiers textes de magasins différents mais avec la même structure.
Je dois intégrer mes fichiers à une base de données globale, calculer de nouvelles tables et variables.
Et pour finir créer des fichiers textes avec ces données pour les exploiter avec un autre logiciel.

Mais attention le gros hic : c'est la taille des données, on parle de millions de lignes. Ma cliente me dit qu'actuellement la base de données fait environ 10Go. Non, non c'est pas une blague...

Donc ma question est : est-ce que Windev 17 va supporter autant de lignes et est-ce que le temps de traitement ne va pas dépasser les 48heures...

Merci d'avance

Perrine

[michel.souris]

Bonjour à tous,

Je suis en plein analyse d'une nouvelle application et je me demande si Windev 17 est le bon outils pour la développer.

Voici ma problèmatique :
Je reçois plusieurs fichiers textes de magasins différents mais avec la même structure.
Je dois intégrer mes fichiers à une base de données globale, calculer de nouvelles tables et variables.
Et pour finir créer des fichiers textes avec ces données pour les exploiter avec un autre logiciel.

Mais attention le gros hic : c'est la taille des données, on parle de millions de lignes. Ma cliente me dit qu'actuellement la base de données fait environ 10Go. Non, non c'est pas une blague...

Donc ma question est : est-ce que Windev 17 va supporter autant de lignes et est-ce que le temps de traitement ne va pas dépasser les 48heures...

Merci d'avance

Perrine

Combien de magasin par jour ?
Combien de fichier par magasin ?
Combien de ligne par fichier ?
Combien de données par ligne ?

Quel type de traitement ? où seront fait les traitements (par programmation, par requêtage SQL) ?

Franchement, et c'est un avis perso, pour de la grosse base je conseillerais pas hyperfile.... par contre que tu script avec Windev 17, 16 ou VB je vois pas de diff' !

[perrine1985]

Cette procédure a lieu une fois par mois, j'ai environ sur 6 magasins voir plus. Chaque magasin possède environ une quinzaine de tables.
Je dois ensuite calculer 6 à 7 tables et environ 30 variables sur les tables existantes.

Et je pense que vu la grosseur des données, elles seront faite par requetage SQL.

Par contre si vous me déconseillez HyperFile, quelles autres solutions me conseillerez-vous ?

[michel.souris]

Cette procédure a lieu une fois par mois, j'ai environ sur 6 magasins voir plus. Chaque magasin possède environ une quinzaine de tables.
Je dois ensuite calculer 6 à 7 tables et environ 30 variables sur les tables existantes.

Et je pense que vu la grosseur des données, elles seront faite par requetage SQL.

Par contre si vous me déconseillez HyperFile, quelles autres solutions me conseillerez-vous ?

Si t'as pas d'argent je peux rien te conseiller mis à part mysql, postgre...

[tatayo]

Bonjour,
Nous utilisons une base MaxDb pour nos applications (70Go environ), qui doit de plus échanger des données dans les deux sens via des fichiers à plat avec un ERP, une WMS et un Front-Office, chacun ayant son propre formalisme.
J'ai donc développé un logiciel qui s'occupe de causer avec tout ce petit monde, actuellement en version 16 (migration vers la 17 prévue sous peu).
Les fichiers en question comportent de 5 à plus de 80 colonnes, et de quelques lignes à plusieurs milliers (certains fichiers pouvant faire plusieurs Mo). Le tout tourne avec des tâches planifiées toutes les 2 à 10 minutes, 7 jours sur 7, certaines pendant les heures ouvrées et d'autres H24, réparties sur 2 serveurs dédiés (plus 1 pour la base).

Windev remplie très bien son rôle ici, les quelques ralentissements étant plutôt du côté de la base avec certaines mises à jour "un peu lourdes".

Pour la base, tu peux regarder du côté de PostGresQL, MaxDb, perso j'éviterai MySql pour son support approximatif du SQL.

Tatayo.

[hpascal]

Bojour

Par contre si vous me déconseillez HyperFile, quelles autres solutions me conseillerez-vous ?

PostgreSQL est un choix parfait pour fonctionnalités et performances
Il y a beaucoup de doc sur internet, il y a quelques livres en Français (mais ce ne sont pas les meilleurs) et un peu plus en anglais

MySql aussi, chacun a ses avantages et inconvénients (je sais, ce genre de phrase bateau ne t'aidera pas beaucoup)

Et puis les deux étant téléchargeables gratuitement, rien ne t'empêche de faire des tests et de comparer les deux sur des gros volumes de données

[OnePoint]

Bonjour,

(je continue avec les SGBD gratuits)

Sans être partisan, si le but est simplement de trouver un remplaçant pour un HyperFileSQL C/S, alors MySQL est un excellent candidat.

Aujourd'hui, on peut reprocher à MySQL:
• sa licence pour la diffusion par une entreprise d'un logiciel non open-source basé sur MySQL (dans ce contexte une licence commerciale est nécessaire), et
• la politique technique et commerciale (pas toujours claire) de son éditeur, la société Oracle (cf. les différentes éditions commerciales de MySQL).
http://www.mysql.fr/products/

Pour une utilisation et un déploiement "en interne" par une entreprise "utilisatrice", les éditions Communautaires de MySQL et de MySQL Cluster sont gratuites.
http://www.mysql.fr/products/community/

Il existe un fork de MySQL qui est totalement compatible et se pose comme alternative open-source et vraiment gratuite: MariaDB
http://fr.wikipedia.org/wiki/MariaDB

La migration "transparente" vers MariaDB permet de préserver les investissements consentis auparavant sur MySQL.

En revanche, toutes ces questions ne se posent pas avec PostgreSQL qui est totalement transparent sur son avenir.

Sinon, le moteur InnoDB gère les transactions ACID et l'intégrité référentielle (et depuis peu, les recherches full-text).
http://www.tux-planet.fr/mysql-les-p...sam-et-innodb/

Sur la comparaison des performances pour les gros volumes de données, apparemment PostgreSQL est meilleur que MySQL, mais ce dernier progresse régulièrement tant pour l'optimisation que pour l'architecture (partitionnement, réplication, cluster...).

A lire en anglais:
<< MySQL vs PostgreSQL >>
http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL

En conclusion:

Je réfléchis plutôt à l'importance de la place du SGBD dans mon projet.
Si dans le projet, je souhaite juste un SGBD pour remplacer HyperFileSQL C/S, alors je choisis la simplicité avec MySQL+moteur InnoDB et j'essaie de rester le plus possible dans les standards du SQL (ce qui n'est pas un problème).
Si les données sont au coeur du projet (robustesse, architecture, disponibilité, performance...), alors PostgreSQL est peut-être plus pertinent.

Quant à la richesse de PostgreSQL, il faut garder à l'esprit que Windev n'est pas capable d'exploiter tout le potentiel de ses type de données.
Peut-être faut-il créer des procédures ou fonctions SQL stockées pour extraire certaines données que les fonction H* et SQL* du WLangage ne permettent pas de lire directement...

[OnePoint]

Je suis en plein analyse d'une nouvelle application et je me demande si Windev 17 est le bon outils pour la développer.

Comme dit précédemment par michel.souris, l'outil de programmation n'est pas fondamental, sous réserve qu'il permette d'exploiter le potentiel du SGBD.

Si tu sais comment t'y prendre avec Windev, alors pas de problème.
En clair, il faut se former.

Voici ma problèmatique :
Je reçois plusieurs fichiers textes de magasins différents mais avec la même structure.
Je dois intégrer mes fichiers à une base de données globale, calculer de nouvelles tables et variables.
Et pour finir créer des fichiers textes avec ces données pour les exploiter avec un autre logiciel.

Mais attention le gros hic : c'est la taille des données, on parle de millions de lignes. Ma cliente me dit qu'actuellement la base de données fait environ 10Go. Non, non c'est pas une blague...

Donc ma question est : est-ce que Windev 17 va supporter autant de lignes et est-ce que le temps de traitement ne va pas dépasser les 48heures...

Donc la question était plutôt: HyperFileSQL Client/Serveur va-t-il supporter autant de lignes...

Toute la question porte sur le type d'utilisation des données:
Par exemple, est-ce que les données d'une table vont être modifiées (modification,suppression d'enregistrement) ou bien n'y aura-t-il que des insertions.
On peut aussi imaginer le cas où les tables cibles sont recréées ex-nihilo à chaque fois...
Que font les requêtes utilisées pour créer les nouvelles tables ?
Les requêtes utilisent-elles des jointures ou des sous-requêtes, et sur quelles données ?

Une fois que ces comportements sont "caractérisés", il est alors possible d'analyser les risques de goulots d'étranglement.
Par exemple la mise à jour des index qui peut ralentir considérablement le SGBD lors de l'ajout de nouvelles lignes dans une table qui contient déjà des dizaines ou centaines de millions de ligne.

Une fois les risques compris, ont peut réfléchir aux solutions.
Par exemple, pour insérer un grand nombre de lignes, utiliser un outil dédié ou des instructions spécifiques performantes (ex LOAD DATA INFILE pour MySQL).
Par exemple le partitionnement.
<< Improving Database Performance with Partitioning >>
http://dev.mysql.com/tech-resources/...titioning.html

Au passage:
• Avec MySQL, les tables partitionnées ne peuvent pas être impliquées dans une relation d'intégrité référentielle.
• HyperFileSQL ne permet pas de partitionner une table.