Serveur HFSQL C/S Avis Stockage données

Bonjour,

J'ai l'intention de prendre un Hébergement de base de données HFSQL C/S (Type Kalanda), la première offre étant limitée a 500Mo.

Si j'ai une base de données avec seulement des identifiants et du texte (maxi 50 caractères par champ) et pas plus de 10 rubriques par fichier, combien de lignes puis-je enregistrer ou stocker pour 500Mo.

Cela me parait petit comme stockage, je ne veux pas stocker de photos, principalement des données GPS (Des réels (exemples : latitude,longitude)).

Si quelqu'un a déjà tester ce genre de solution, qu'en est-il si je veux tester une synchronisation des données entre une application Windev mobile et Windev (PC), est-ce performant ?

Comme disait un philosophe (bac de philo aujourd'hui) : ben, ça dépend... Tu as 3 heures...

Soyons sérieux un instant. Atteindre 500 Mo avec des fichiers HF (sans mémo), ben faut y aller... Et c'est bien la problématique. Si tu regardes dans ton analyse, chaque fichier te donne la taille d'un enregistrement. A toi de faire le calcul car tu sais la proportion entre chaque table.

La question c*n n°1 : quelle volumétrie espères tu ?
La question c*n n°2 : tu n'as pas fait de test ?
La question c*n n°3 : si tu mets ta base en ligne, c'est que tu as potentiellement des clients qui vont payer un abonnement, non ? (et changer d'abonnement si le besoin s'en fait ressentir)

Bonjour, tout d'abord merci d'avoir pris le temps de me répondre.

Oui, j'ai déjà fait des simulations de remplissages de fichiers HF classique pour voir ce que cela donner, je poser cette question ici pour avoir d'autres avis.

Donc :
Réponse à la question c*n n°1 : Ceci est ma première expérience avec un outil comme Kalanda et je me demandais si ces 500 Mo aller me limiter ou pas, donc ce que j’espère c'est que je ne dépasse pas ce stockage.
Réponse à la question c*n n°2 : Si bien sur mais je voulais avoir d'autre avis.
Réponse à la question c*n n°3 : Ceci est une très intéressant en acceptant l'idée que des gens payent un abonnement a mon service et qui résoudrait toutes les questions c*ns a venir.

Citation:

---

Atteindre 500 Mo avec des fichiers HF (sans mémo), ben faut y aller...

---

Je retiens donc ce conseil, s'il y en a d'autre je prend :
- Éviter les mémo en C/S

Citation:

---

Envoyé par NahMean

- Éviter les mémo en C/S

---

Qui a dit celà ?
Personne ici en tout cas.

Citation:

---

Qui a dit celà ?
Personne ici en tout cas.

---

Désolé, j'ai mal interprété ce qu'a écrit frenchsting.

J'ai refait quelque test, même avec des mémos, c'est vrai que je ne devrait pas être trop inquiet tant que je ne stocke pas des images.

La taille d'un enregistrement est de 318 octets pour un de mes fichiers le plus important.

Pour info, je ne suis pas tellement d'accord avec ce qui est dit plus haut.

J'ai eu à corriger une analyse dans laquelle on stockait des commentaires dans des champs textes de 1000 a 5000 caractères
Or, meme quand cette rubrique était vide, windev allouait bien l'espace dans le fichiers; résultats pour 100 000 enregistrements le fichier frolait le giga alors qu'il était plein...de vide.

Passer aux mémos à corrigé cet état de fait: le fichier a fondu et la taille du mémo correspondait aux textes effectivement saisis.

Personnellement quand je code, si les chaines stockées dépassent 250 caractères, je les passe sur un mémo. Ce n'est ni plus dangereux ni moins fiable.

Citation:

---

Envoyé par RainbowBox

J'ai eu à corriger une analyse dans laquelle on stockait des commentaires dans des champs textes de 1000 a 5000 caractères
Or, meme quand cette rubrique était vide, windev allouait bien l'espace dans le fichiers; résultats pour 100 000 enregistrements le fichier frolait le giga alors qu'il était plein...de vide.

---

Oui, en format HF5.5. Normalement en HFclassic tu n'as pas ce pb.

Citation:

---

Envoyé par RainbowBox

Personnellement quand je code, si les chaines stockées dépassent 250 caractères, je les passe sur un mémo. Ce n'est ni plus dangereux ni moins fiable.

---

Le problème des mémos, n'est pas les rubriques texte, mais les rubriques binaires (RTF, JPEG,...). Dans ce cas, le fichier augmente rapidement en taille (RTF notamment).

Sauf erreur de ma part il s'agissait bien de fichiers Classic et non 5.5 (je vérifierais à l'occasion)
Concernant les mémos binaires oui ils peuvent prendre beaucoup de place mais c'est à ça qu'ils servent...celui qui stocke une vidéo dans une base de données n'a qu'a s'en prendre à lui même.

Tout à fait, c'est bien pour cela que je fais une mise en garde là dessus : si on veut une bdd "compacte", il faut proscrire ce genre de mémos.

Bah oui mais dis comme ça c'est un peu restrictif à mon gout...je n'irais pas jusqu'à les proscrire. Disons qu'ils peuvent tout stocker mais que c'est pas pour ça qu'on doit tout y mettre.

A ce compte là, je pourrais dire "ne pas se servir d'un Samsung, c'est Android et c'est naze", mais ça serait tout aussi restrictif. Y'a de l'intéressant partout.