helios a écritALain Montfranc a écrit :helios a écritAh, y'a pas d'index dans les SGBD MV ? Ni de sequences ?
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait plus
tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout les
champs d'une table et comme il utilise pas des methode prehistorique
c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
helios a écrit
ALain Montfranc a écrit :
helios a écrit
Ah, y'a pas d'index dans les SGBD MV ? Ni de sequences ?
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait plus
tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout les
champs d'une table et comme il utilise pas des methode prehistorique
c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
helios a écritALain Montfranc a écrit :helios a écritAh, y'a pas d'index dans les SGBD MV ? Ni de sequences ?
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait plus
tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout les
champs d'une table et comme il utilise pas des methode prehistorique
c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
ALain Montfranc a écrit :helios a écritALain Montfranc a écrit :helios a écritAh, y'a pas d'index dans les SGBD MV ? Ni de sequences ?
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait plus
tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout les
champs d'une table et comme il utilise pas des methode prehistorique c'est
performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec une louche
?
ALain Montfranc a écrit :
helios a écrit
ALain Montfranc a écrit :
helios a écrit
Ah, y'a pas d'index dans les SGBD MV ? Ni de sequences ?
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait plus
tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout les
champs d'une table et comme il utilise pas des methode prehistorique c'est
performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec une louche
?
ALain Montfranc a écrit :helios a écritALain Montfranc a écrit :helios a écritAh, y'a pas d'index dans les SGBD MV ? Ni de sequences ?
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait plus
tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout les
champs d'une table et comme il utilise pas des methode prehistorique c'est
performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec une louche
?
helios a écritALain Montfranc a écrit :helios a écritALain Montfranc a écrit :helios a écritAh, y'a pas d'index dans les SGBD MV ? Ni de sequences ?
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait
plus tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout
les champs d'une table et comme il utilise pas des methode
prehistorique c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec une
louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
helios a écrit
ALain Montfranc a écrit :
helios a écrit
ALain Montfranc a écrit :
helios a écrit
Ah, y'a pas d'index dans les SGBD MV ? Ni de sequences ?
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait
plus tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout
les champs d'une table et comme il utilise pas des methode
prehistorique c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec une
louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
helios a écritALain Montfranc a écrit :helios a écritALain Montfranc a écrit :helios a écritAh, y'a pas d'index dans les SGBD MV ? Ni de sequences ?
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait
plus tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout
les champs d'une table et comme il utilise pas des methode
prehistorique c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec une
louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
ALain Montfranc a écrit :helios a écritALain Montfranc a écrit :helios a écritALain Montfranc a écrit :helios a écritAh, y'a pas d'index dans les SGBD MV ? Ni de sequences ?
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait plus
tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout les
champs d'une table et comme il utilise pas des methode prehistorique
c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec une
louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
c'est un bulldozer écologique et qui a des outils de précisions et qui en
plus est gratuit chez certain distributeur
ALain Montfranc a écrit :
helios a écrit
ALain Montfranc a écrit :
helios a écrit
ALain Montfranc a écrit :
helios a écrit
Ah, y'a pas d'index dans les SGBD MV ? Ni de sequences ?
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait plus
tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout les
champs d'une table et comme il utilise pas des methode prehistorique
c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec une
louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
c'est un bulldozer écologique et qui a des outils de précisions et qui en
plus est gratuit chez certain distributeur
ALain Montfranc a écrit :helios a écritALain Montfranc a écrit :helios a écritALain Montfranc a écrit :helios a écritAh, y'a pas d'index dans les SGBD MV ? Ni de sequences ?
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait plus
tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout les
champs d'une table et comme il utilise pas des methode prehistorique
c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec une
louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
c'est un bulldozer écologique et qui a des outils de précisions et qui en
plus est gratuit chez certain distributeur
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait
plus tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout
les champs d'une table et comme il utilise pas des methode
prehistorique c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec
une louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
c'est un bulldozer écologique et qui a des outils de précisions et qui
en plus est gratuit chez certain distributeur
Et la marmotte... :-D
Un machin qui construit systématiquement tous les index possibles
(that's you kil dites) est une bouze inoptilisable
lol
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait
plus tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout
les champs d'une table et comme il utilise pas des methode
prehistorique c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec
une louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
c'est un bulldozer écologique et qui a des outils de précisions et qui
en plus est gratuit chez certain distributeur
Et la marmotte... :-D
Un machin qui construit systématiquement tous les index possibles
(that's you kil dites) est une bouze inoptilisable
lol
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait
plus tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant tout
les champs d'une table et comme il utilise pas des methode
prehistorique c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec
une louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
c'est un bulldozer écologique et qui a des outils de précisions et qui
en plus est gratuit chez certain distributeur
Et la marmotte... :-D
Un machin qui construit systématiquement tous les index possibles
(that's you kil dites) est une bouze inoptilisable
lol
ils construit aucun fichiers d'index mais un dictionnaires de fichier ce qui
remplace tout les index possibles sur le fichier (table) ce qui est différent
ils construit aucun fichiers d'index mais un dictionnaires de fichier ce qui
remplace tout les index possibles sur le fichier (table) ce qui est différent
ils construit aucun fichiers d'index mais un dictionnaires de fichier ce qui
remplace tout les index possibles sur le fichier (table) ce qui est différent
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait
plus tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant
tout les champs d'une table et comme il utilise pas des methode
prehistorique c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec
une louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
c'est un bulldozer écologique et qui a des outils de précisions et
qui en plus est gratuit chez certain distributeur
Et la marmotte... :-D
Un machin qui construit systématiquement tous les index possibles
(that's you kil dites) est une bouze inoptilisable
lol
ils construit aucun fichiers d'index mais un dictionnaires de fichier ce
qui remplace tout les index possibles sur le fichier (table) ce qui est
différent
bref les truc prehistorique sous SQL sont des bouzes a coté et en
matiere inoptibilisabilité a quoi cela servirait de gonfler le moteur
d'une MERCEDES 1200 SEL (V24 TD ) pour rouler en France ou la vitesse
est limité a 130km/h
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait
plus tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant
tout les champs d'une table et comme il utilise pas des methode
prehistorique c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec
une louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
c'est un bulldozer écologique et qui a des outils de précisions et
qui en plus est gratuit chez certain distributeur
Et la marmotte... :-D
Un machin qui construit systématiquement tous les index possibles
(that's you kil dites) est une bouze inoptilisable
lol
ils construit aucun fichiers d'index mais un dictionnaires de fichier ce
qui remplace tout les index possibles sur le fichier (table) ce qui est
différent
bref les truc prehistorique sous SQL sont des bouzes a coté et en
matiere inoptibilisabilité a quoi cela servirait de gonfler le moteur
d'une MERCEDES 1200 SEL (V24 TD ) pour rouler en France ou la vitesse
est limité a 130km/h
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait
plus tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant
tout les champs d'une table et comme il utilise pas des methode
prehistorique c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec
une louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
c'est un bulldozer écologique et qui a des outils de précisions et
qui en plus est gratuit chez certain distributeur
Et la marmotte... :-D
Un machin qui construit systématiquement tous les index possibles
(that's you kil dites) est une bouze inoptilisable
lol
ils construit aucun fichiers d'index mais un dictionnaires de fichier ce
qui remplace tout les index possibles sur le fichier (table) ce qui est
différent
bref les truc prehistorique sous SQL sont des bouzes a coté et en
matiere inoptibilisabilité a quoi cela servirait de gonfler le moteur
d'une MERCEDES 1200 SEL (V24 TD ) pour rouler en France ou la vitesse
est limité a 130km/h
helios a écritils construit aucun fichiers d'index mais un dictionnaires de fichier
ce qui remplace tout les index possibles sur le fichier (table) ce qui
est différent
Peux tu expliciter ta notion de "dictionnaire de fichier" avec exemple ?
helios a écrit
ils construit aucun fichiers d'index mais un dictionnaires de fichier
ce qui remplace tout les index possibles sur le fichier (table) ce qui
est différent
Peux tu expliciter ta notion de "dictionnaire de fichier" avec exemple ?
helios a écritils construit aucun fichiers d'index mais un dictionnaires de fichier
ce qui remplace tout les index possibles sur le fichier (table) ce qui
est différent
Peux tu expliciter ta notion de "dictionnaire de fichier" avec exemple ?
helios a écrit :
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait
plus tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant
tout les champs d'une table et comme il utilise pas des methode
prehistorique c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec
une louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
c'est un bulldozer écologique et qui a des outils de précisions et
qui en plus est gratuit chez certain distributeur
Et la marmotte... :-D
Un machin qui construit systématiquement tous les index possibles
(that's you kil dites) est une bouze inoptilisable
lol
ils construit aucun fichiers d'index mais un dictionnaires de fichier
ce qui remplace tout les index possibles sur le fichier (table) ce qui
est différent
Un "dictionnaires de fichier" remplace tous les index en indexant tous
les champs d'une table ? Bizarrement, dans la vraie vie, il y plein de
champs sur lesquels on aura *jamais* besoin d'un index dessus.
En mettre partout ne fait donc que polluer l'espace disque (et le pacte
écologique hein !), et chuter les performances en écriture, que le sgbd
soit une F1 ou un cycle.
ça vous parait pas évident que la construction d'un index prend du temps
? ça doit être encore les couches propres des processus intégrés en
accès direct qui réduisent ce temps à l'infiniment petit ?
Et un vélo, c'est bien, maintenable par une seule personne. Pour aller
au travail, c'est parfait pour la génération d'après. La F1, ça
consomme, faut changer les pneus tout le temps, et la réparation n'est
pas à porté du pilote, sinon ça ferait du chômage au stand. Au final, on
choisit une bonne berline custom (comme postgresql) pour aller loin,
puisque vous aimez les métaphores automobiles.bref les truc prehistorique sous SQL sont des bouzes a coté et en
matiere inoptibilisabilité a quoi cela servirait de gonfler le moteur
d'une MERCEDES 1200 SEL (V24 TD ) pour rouler en France ou la vitesse
est limité a 130km/h
Pour tracter vos 38 tonnes de conneries ?
helios a écrit :
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait
plus tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant
tout les champs d'une table et comme il utilise pas des methode
prehistorique c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec
une louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
c'est un bulldozer écologique et qui a des outils de précisions et
qui en plus est gratuit chez certain distributeur
Et la marmotte... :-D
Un machin qui construit systématiquement tous les index possibles
(that's you kil dites) est une bouze inoptilisable
lol
ils construit aucun fichiers d'index mais un dictionnaires de fichier
ce qui remplace tout les index possibles sur le fichier (table) ce qui
est différent
Un "dictionnaires de fichier" remplace tous les index en indexant tous
les champs d'une table ? Bizarrement, dans la vraie vie, il y plein de
champs sur lesquels on aura *jamais* besoin d'un index dessus.
En mettre partout ne fait donc que polluer l'espace disque (et le pacte
écologique hein !), et chuter les performances en écriture, que le sgbd
soit une F1 ou un cycle.
ça vous parait pas évident que la construction d'un index prend du temps
? ça doit être encore les couches propres des processus intégrés en
accès direct qui réduisent ce temps à l'infiniment petit ?
Et un vélo, c'est bien, maintenable par une seule personne. Pour aller
au travail, c'est parfait pour la génération d'après. La F1, ça
consomme, faut changer les pneus tout le temps, et la réparation n'est
pas à porté du pilote, sinon ça ferait du chômage au stand. Au final, on
choisit une bonne berline custom (comme postgresql) pour aller loin,
puisque vous aimez les métaphores automobiles.
bref les truc prehistorique sous SQL sont des bouzes a coté et en
matiere inoptibilisabilité a quoi cela servirait de gonfler le moteur
d'une MERCEDES 1200 SEL (V24 TD ) pour rouler en France ou la vitesse
est limité a 130km/h
Pour tracter vos 38 tonnes de conneries ?
helios a écrit :
le systèmes gèrent lui même les index en interne
Ah... Il devine donc tout seul le type de requete qui sera fait
plus tard. Balaise !
il devine rien du tout il prevoit simplement tout en indexant
tout les champs d'une table et comme il utilise pas des methode
prehistorique c'est performant
tous les champs ? Et les n-uplets de champs aussi je suppose ?
methode bulldozer quoi...
lorsque on a un bulldozer pourquoi continué de creuser le sol avec
une louche ?
Parce qu'un bulldozer pollue et est inutilisable pour du travail de
précision.
c'est un bulldozer écologique et qui a des outils de précisions et
qui en plus est gratuit chez certain distributeur
Et la marmotte... :-D
Un machin qui construit systématiquement tous les index possibles
(that's you kil dites) est une bouze inoptilisable
lol
ils construit aucun fichiers d'index mais un dictionnaires de fichier
ce qui remplace tout les index possibles sur le fichier (table) ce qui
est différent
Un "dictionnaires de fichier" remplace tous les index en indexant tous
les champs d'une table ? Bizarrement, dans la vraie vie, il y plein de
champs sur lesquels on aura *jamais* besoin d'un index dessus.
En mettre partout ne fait donc que polluer l'espace disque (et le pacte
écologique hein !), et chuter les performances en écriture, que le sgbd
soit une F1 ou un cycle.
ça vous parait pas évident que la construction d'un index prend du temps
? ça doit être encore les couches propres des processus intégrés en
accès direct qui réduisent ce temps à l'infiniment petit ?
Et un vélo, c'est bien, maintenable par une seule personne. Pour aller
au travail, c'est parfait pour la génération d'après. La F1, ça
consomme, faut changer les pneus tout le temps, et la réparation n'est
pas à porté du pilote, sinon ça ferait du chômage au stand. Au final, on
choisit une bonne berline custom (comme postgresql) pour aller loin,
puisque vous aimez les métaphores automobiles.bref les truc prehistorique sous SQL sont des bouzes a coté et en
matiere inoptibilisabilité a quoi cela servirait de gonfler le moteur
d'une MERCEDES 1200 SEL (V24 TD ) pour rouler en France ou la vitesse
est limité a 130km/h
Pour tracter vos 38 tonnes de conneries ?
ils construit aucun fichiers d'index mais un dictionnaires de fichier
ce qui remplace tout les index possibles sur le fichier (table) ce
qui est différent
Un "dictionnaires de fichier" remplace tous les index en indexant tous
les champs d'une table ? Bizarrement, dans la vraie vie, il y plein de
champs sur lesquels on aura *jamais* besoin d'un index dessus.
En mettre partout ne fait donc que polluer l'espace disque (et le
pacte écologique hein !), et chuter les performances en écriture, que
le sgbd soit une F1 ou un cycle.
non car j'ai dit remplace pas créer les fichiers index
ça vous parait pas évident que la construction d'un index prend du
temps ? ça doit être encore les couches propres des processus
intégrés en accès direct qui réduisent ce temps à l'infiniment petit ?
Et un vélo, c'est bien, maintenable par une seule personne. Pour aller
au travail, c'est parfait pour la génération d'après. La F1, ça
consomme, faut changer les pneus tout le temps, et la réparation n'est
pas à porté du pilote, sinon ça ferait du chômage au stand. Au final,
on choisit une bonne berline custom (comme postgresql) pour aller
loin, puisque vous aimez les métaphores automobiles.bref les truc prehistorique sous SQL sont des bouzes a coté et en
matiere inoptibilisabilité a quoi cela servirait de gonfler le
moteur d'une MERCEDES 1200 SEL (V24 TD ) pour rouler en France ou la
vitesse est limité a 130km/h
Pour tracter vos 38 tonnes de conneries ?
La MERCEDES 1200 SEL est une voiture d'hyper luxe qui raméne la
royce-rolls au niveau voiture de créve la faim (le nombre de MERCEDES
1200 SEL se compte sur les doigts d'une main et est construite sur
commande avec un delais de 3ans pour la livraison meme Bill Gate n'en
as pas une) par contre vue la puissance du moulin je pense quel
pourrait tracter un 38T en remorque et etre encore bride par le bridage
mercedes (250km/h) evidedemnt dans ces conditions le 100km/h depart
arreté en moins de 3secondes serait sans doute pas possible :-)
ils construit aucun fichiers d'index mais un dictionnaires de fichier
ce qui remplace tout les index possibles sur le fichier (table) ce
qui est différent
Un "dictionnaires de fichier" remplace tous les index en indexant tous
les champs d'une table ? Bizarrement, dans la vraie vie, il y plein de
champs sur lesquels on aura *jamais* besoin d'un index dessus.
En mettre partout ne fait donc que polluer l'espace disque (et le
pacte écologique hein !), et chuter les performances en écriture, que
le sgbd soit une F1 ou un cycle.
non car j'ai dit remplace pas créer les fichiers index
ça vous parait pas évident que la construction d'un index prend du
temps ? ça doit être encore les couches propres des processus
intégrés en accès direct qui réduisent ce temps à l'infiniment petit ?
Et un vélo, c'est bien, maintenable par une seule personne. Pour aller
au travail, c'est parfait pour la génération d'après. La F1, ça
consomme, faut changer les pneus tout le temps, et la réparation n'est
pas à porté du pilote, sinon ça ferait du chômage au stand. Au final,
on choisit une bonne berline custom (comme postgresql) pour aller
loin, puisque vous aimez les métaphores automobiles.
bref les truc prehistorique sous SQL sont des bouzes a coté et en
matiere inoptibilisabilité a quoi cela servirait de gonfler le
moteur d'une MERCEDES 1200 SEL (V24 TD ) pour rouler en France ou la
vitesse est limité a 130km/h
Pour tracter vos 38 tonnes de conneries ?
La MERCEDES 1200 SEL est une voiture d'hyper luxe qui raméne la
royce-rolls au niveau voiture de créve la faim (le nombre de MERCEDES
1200 SEL se compte sur les doigts d'une main et est construite sur
commande avec un delais de 3ans pour la livraison meme Bill Gate n'en
as pas une) par contre vue la puissance du moulin je pense quel
pourrait tracter un 38T en remorque et etre encore bride par le bridage
mercedes (250km/h) evidedemnt dans ces conditions le 100km/h depart
arreté en moins de 3secondes serait sans doute pas possible :-)
ils construit aucun fichiers d'index mais un dictionnaires de fichier
ce qui remplace tout les index possibles sur le fichier (table) ce
qui est différent
Un "dictionnaires de fichier" remplace tous les index en indexant tous
les champs d'une table ? Bizarrement, dans la vraie vie, il y plein de
champs sur lesquels on aura *jamais* besoin d'un index dessus.
En mettre partout ne fait donc que polluer l'espace disque (et le
pacte écologique hein !), et chuter les performances en écriture, que
le sgbd soit une F1 ou un cycle.
non car j'ai dit remplace pas créer les fichiers index
ça vous parait pas évident que la construction d'un index prend du
temps ? ça doit être encore les couches propres des processus
intégrés en accès direct qui réduisent ce temps à l'infiniment petit ?
Et un vélo, c'est bien, maintenable par une seule personne. Pour aller
au travail, c'est parfait pour la génération d'après. La F1, ça
consomme, faut changer les pneus tout le temps, et la réparation n'est
pas à porté du pilote, sinon ça ferait du chômage au stand. Au final,
on choisit une bonne berline custom (comme postgresql) pour aller
loin, puisque vous aimez les métaphores automobiles.bref les truc prehistorique sous SQL sont des bouzes a coté et en
matiere inoptibilisabilité a quoi cela servirait de gonfler le
moteur d'une MERCEDES 1200 SEL (V24 TD ) pour rouler en France ou la
vitesse est limité a 130km/h
Pour tracter vos 38 tonnes de conneries ?
La MERCEDES 1200 SEL est une voiture d'hyper luxe qui raméne la
royce-rolls au niveau voiture de créve la faim (le nombre de MERCEDES
1200 SEL se compte sur les doigts d'une main et est construite sur
commande avec un delais de 3ans pour la livraison meme Bill Gate n'en
as pas une) par contre vue la puissance du moulin je pense quel
pourrait tracter un 38T en remorque et etre encore bride par le bridage
mercedes (250km/h) evidedemnt dans ces conditions le 100km/h depart
arreté en moins de 3secondes serait sans doute pas possible :-)
