J'ai besoin de stocker des chaînes de plus de 2000 caractères.
J'ai essayer le type LONG mais ça ne marche pas!
 
Auriez vous une idée?

des bourrins déclarent plusieurs colonnes de varchar2(2000).
sinon tu fais une table reliée où tu stockes un varchar2(2000) et un numéro de séquence, mais C lourd à gérer. sinon j'peux pas plus, j'ai jamais eu à stocker autant dans un champ

En fait c'est pour stocker une chaîne qui contient des coordonnées de la forme :
012,452789,145.....125,145 qui constituent un polygone.
 
Dans ma table à chaque n° de polygone je stocke une chaîne qui m'indique les coordonnées du contour du polygone.
Jusqu'ici pas de problème, mais maintenant je doit stocker des ensembles de polygones donc avec bcp plus de points et ça dépasse 2000 caractères
Si t'as une autre idée??

ben c'est de faire une table avec un champ pour chaque coordonnée, C plus lent, mais c'est plus propre.

J'y ai pensé aussi...
mais je suis pas sûr que ce soit plus propre parce que pour un polygone normal, j'ai qd même 36000 polygones qui sont en moyenne constitués de 400 coordonnées et ça doit aller jusqu'a 25000 au moins. Donc je te dit pas le nombre de lignes de la table. Déjà rien que 400*36000....
Non?

36000 * 400 = 14.4M lignes...
 
Bon, ça fait gros, mais ce sera toujours plus propre que de stocker des chaînes de 2000 caractères. Et si tu gères bien tes tablespace et tes index, ce ne sera pas trop long.
 
Sans compter que, pour le traitement, l'extraction dans un tableau sera bien plus aisée.

Merci, je vais soumettre l'idée aux autorités compétentes.
Je ferais encore sûrement appel à vous pour les index et tablechezpaskoi.
 
Merci bcp!

putain, des polygones à 400 côtés ...

Ouaip, ça fait peur... Sa table va taper dans les millions de lignes, il y a intérêt à assurer la purge!!!
 
Mais bon, mieux valent 100M lignes et un code tout simple que moins de lignes et une sale fonction d'extraction des données cuisinée et inmaintenable.
 
Enfin, c'est mon point de vue.

Ce sont en fait les communes de la france et c'est précis comme pas possible!
 
Les coordonnées sont par ex: 123,456,789,987,654,321,123,456
Les points du polygones sont donc:
(123,456)(789,987)(654,321)(123,456)
D'où pour une commune il y a pas mal de point(ça marche), pour un département (c'est ce que j'essaye) c'est le tour de plusieurs communes donc plusieurs fois le nombre de points d'une commune. Sans parler des régions et encore moins de la france!!!

Fred999>ma fonction est toute con: je récupère la ligne et par la fonction explode en php j'en fait un tableau. Ensuite la fonction polygone prend en paramètre ce tableau et le tour est joué c'est le cas de le dire!

si y'a des regroupement, y'a des moyens pour organiser tout ça par hiérarchie. une bonne petite analyse avant permet d'y voir plus clair et de ne pas faire des conneries.

Tu veut regrouper quoi?
Je pense pas que ce soit faisable ici, car la BDD des coordonnées nous viens de l'IGN et à mon avis, si c'était possible, ce serait déjà fait.
En plus, en y réfléchissant c'est impossible à réaliser. Il faudrait regarder les limites en commun entre les communes et en déduire le contour du département. Cela représenterait bcp trop de calcul. Et le temps d'attente sur internet
C'est sûr qu'au niveau analyse ce serait préférable. On ne garderait que les coordonnées des communes, on stockerai dans une autre table les n° des communes pour chaque département. Après il n'y aurait plus qu'a regarder quelles sont les coordonnées les communes qui ne sont pas en double pour un département et les tracer en live. Mais le "plus qu'a" ça en fait des calculs!!!

Tu as une seule table avec un champ type de données (ville, commune, département...) ou plusieurs tables, une par type???
 
Ca peut aider...

En fait, les données telles qu'on les a de l'IGN, c'est une table avec le n° de la commune le nom les coordonnées et le type (dept,commune,région) et d'autres champs moins importants.
Mais, en quoi ça aiderai?

A faire le truc le plus performant possible et le plus propre.
maintenant, si c'est pas possible ...  

 
Supposons que tu n'aies qu'une table.
 
Tu cherches les coordonnées d'un département, il y a 90000 communes en France et une centaine de départements... Tu vois la différence de taille entre les deux tables au niveau de la recherche.
 
Sachant que fonctionnellement, on n'est pas près de modifier le découpage régions/départements/communes...

[edit]--Message édité par Fred999--[/edit]

Comment tu ferai avec des regroupements?
Explique un petit peu ta solution STP, peut être que ça m'apportera une piste.
 
Merci

Ouais je vois ce que tu veut dire Fred, j'y ai songé.
Une table commune comme je fais jusqu'ici, aucun pbr
Une table pr les depts avec là un champ pour une coordonnées et donc plein de lignes par dept
De même pour les régions et la france.
C'est sûr que ça enlève un paquet de ligne. Il en restera qd même un bon 1/2 million!
Ce sera la solution retenue si je n'arrive pas à stocker des champs de plus de 2000 caractères.
 
Merci beaucoup!

Putain, va falloir o/c ton duron 700 plus que 910 pour faire tourner ta BDD...je veux bien te preter le mien ahaha, jusqu'au 17 juin, apres, nvle carte mere, nvl o/c, et un putain de reseau !!!

Attendez sous Oracle il y a un type de données pour stocker jusqu'à plus d'1 Go de données par enregistrement (si si il n'y a pas d'erreur c'est bien un GIGA que j'ai voulu écrire )
En revanche je ne me souviens plus lequel c'est précisément, ce doit être BLOB ou LONG RAW.  
 
Mais si tu as accès à l'aide d'Oracle, vas vérifier, c'est sûr il existe un type de données dédié à ce genre de stockage d'info.