Bonjour,
 
J'ai une table dont je connais pas à l'avance le nombre de colonnes. Je veux faire un select sur toutes les colonnes commençant par un certain mot. Est-ce possible?
 
Merci!
 

pas dans le cas general  a ma connaissance
 
mais il y a peut etre moyen avec un show column de generer la requete qui va bien  
 

T'es obligé d'avoir le nom de tes colonnes ou bien tu prends tout avec *
 
Je pense que le plus simple (y'a peut être des truc tordus ) serait de générer la requête qui va bien dans un langage (je  suppose que tu utilises autre chose qu'un client du sgbd )

Par exemple, avec JDBC, tu peux obtenir des meta-informations dont les noms des colonnes. Mais c'est jouable avec n'importe quel autre langage.
 
(je  suppose que tu utilises autre chose qu'un client du sgbd)
 
Moi aussi

le fait de vouloir filtrer par le nom des colonnes, c'est que le nom des colonnes fait partie des données à gérer.
à partir de là, il y a un problème de conception.
 
en effet, le modèle des données doit être une chose qu'on maîtrise parfaitement, et qui est totalement figé. il doit être dénué de toute information. c'est lui le conteneur des données, il n'en fait pas partie.
 
bref, imaginons que tu as une table actuellement :
 
matable
---------------
id
propriete1
propriete2
propriete3
 
Avec "id" est l'ensemble de champ définisant la clé primaire
"prorieteX" l'ensemble des champs "inconnus"
 
Alors tu peux parfaitement dématérialiser ta table de la façon suivante :
 
columns
----------
col_id
nom
 
values
----------
id (la clé de l'ancienne table)
col_id
value
 
dans ce nouveau modèle, on ajoute "col_id" dans la clé "id" de la table "values".
si besoin, on peut faire une table de référence supplémentaire "table" (qui contient un "tab_id" qui sera rapporté dans la clé de "values" ) contenant la liste des noms de tables qu'on veut gérer de la sorte. on pourra ainsi stocker un nombre infini de "tables" dans seulement ces 3 tables.
 
a noter qu'on peut aussi ajouter une quatrième table "tab_columns" qui va permettre de faire le lien entre "tab_id" et "col_id" (on aura une FK dans "values" qui pointe dessus). cette table permettra de vérifier que les données saisies dans "values" pour une table donnée correspondent ben à une colonne existante pour la dite table.
 
 
exemple de ce que ça peut donner :

Ca c'est ton point de vue qui se base purement et uniquement sur la théorie Avoir une base qui s'autodonne du sens ça permet de faire des choses que tu ferais bien moins facilement si la structure est fixe et que tu dois passer par un système comme tu l'évoques
 
Maintenant je pense qu'il y a quand même un souci quelque part dans le cas évoqué parce qu'en effet tu dois quand même être capable de savoir où tu vas avec des règles fixes (mais pas aussi dénuées de sens qu'on pourrait le croire)

j'ai pas dit que le modèle n'avait pas de sens, j'ai dit qu'il était dénué d'information.
 
par exemple, t'as une table "quizz_résultat".
 
en aucun cas il ne faut avoir les colonnes :
 
utilisateur_id
resultat_question_1
resultat_question_2
resultat_question_3
resultat_question_4
resultat_question_5
resultat_question_6
resultat_question_7
 
Car ici, ton modèle donne une information : un quizz contient 7 questions.
 
Non, à la place, tu fais :
 
utilisateur_id
question_num
resultat
 
Là, t'as plus d'information. Et mieux, tu peux maintenant avoir autant de questions que du veux dans ton quizz.
 
Le second modèle n'est pas moins dénué de sens que le premier. Au contraire. Par contre, il est dépourvu d'information.

Entièrement d'accord, celà dit dans certains cas, donner une info peut être utile quand même, bien entendu pas pour faire ça

Fais voir ton cas pratique, alors.  
 
Je viens de coder en JDBC ce dont tu parles il y a qq heures, mais si je ne connais pas le nom des colonnes, c'est parce que je dois exécuter le contenu d'un fichier SQL arbitraire, pour un outil purement technique. Si tu commences à discriminer les colonnes, ça sent l'information fonctionnelle...
 
Ceci dit, le contre-exemple de MagicBuzz n'est pas tout à fait pertinent/convaincant. Il arrive parfois que l'on fige champs_1, champs_2 sans passer par une table supplémentaire, parce qu'on a que deux valeurs à stocker dans tous les cas, et parce qu'on est fat ou qu'on a la c0wb0y attitude.. 2 ou 3 champs, disons. Bon, au delà, effectivement, ça commence à sentir l'excès de paresse, et ça ne va plus très bien quand on commence à tenter des "select champs*" dynamiques sur des colonnes a priori pas connues comme le veut leflo...
 
Faut voir, ça peut rester justifiable mais on n'en sait pas plus sur le cas d'espèce.
 

ben c'est sûr que pour une application de gestion de famille, tu vas pas faire "parent_sexe / parent_id" mais "père / mère"
 
ensuite, la dénormalisation intervient surtout dans l'étude des performances et de l'utilisation de la base. par contre, elle ne doit jamais être faite du premier abords.

Premier abord = schema logique. Si tu y consacres du temps. Dans la vraie vie, c'est souvent une chimère. Au delà, c'est à dire au stade "physique", je me casserais pas la tête avec les cas simples. Dans la pratique, faut pas forcément attendre des questions de perf pour dénormaliser. Si je reprends ton exemple supra, je me vois mal prendre la solution normalisée, même pour une application enterprise, même en l'absence de contraintes de perf.
 
Bien sûr, faut éviter les trucs à la con genre "telephone1" et "telephone2" des applis à la années 90, ou tu pestais bien fort dès que tu devais stocker un 3è numéro. Encore que si on est trop limite que pour implémenter n numéros dans le UI, ça vaut peut-être pas la peine de se tracasser pour la DB.
 
'fin bon, on parle de cas triviaux là. Dès que ça devient un peu sérieux, on se la joue plus strict. J'espère.  

L'ERP sur lequel je travaille utilise énormément l'astuce que j'ai donné pour dématérialiser les tables.
et c'est hyper pratique.
 
genre j'ai un fauteuil. je veux dire que le bas de caisse est en chêne, les cousins en mousse condensée, le revêtement des cousons en tissus machin et les accoudoirs en cuirs.
 
j'ai le choix entre créer 4 champs, avec 4 tables de correspondances, et être emmerdé le jour où mon produit n'est plus un canapé mais une bougie (là j'aurais d'autres propriétés), ou utiliser ce système qui permet d'associer n propriétés à mon produit, dont les valeurs possibles sont toutes présentes dans une "table fourre tout" identifiés par un code "table".
 
ce système, en clair, pour une baisse de performances très faible (voir même un gain puisqu'on a moins de table de correspondances), permet de stocker tout et n'importe quoi au gré des désirs de l'utilisateur. et surtout, via une interface très simple et générique, on peut permettre à l'utilisateur de créer ses propres propriétés avec leurs tables de correspondances associées, sans jamais toucher au modèle.

Pure hypothese : ce ne serait pas possible d'aller chercher le nom des colonnes dans une table systeme du genre SYSTABLE where TABLE = matable?

si, parfaitement. mais ensuite en pur SQL il sera impossible de générer une requête à la volée à partir de ça.

Forcément, s'il s'agit de stocker aussi bien des fauteuils que de la crème pour visage, on parle d'autre chose
 
C'est un cas à part où les meta-data (les caractéristiques qui nous intéressent) constituent des données en elles-mêmes. Avec un ERP, on tombe dans ce cas de figure. Une personne par exemple peut avoir un nombre indéfini de caractéristiques auxquelles on s'interesse ou non, et on reporte sur l'applicatif une partie de ce que la structure de DB nous donnait dans un modèle plus académique... Y'a rien de mal à ça.
 
polo> Oui, tu peux tout faire, mais la question est celle de la portabilité et de l'usage que tu veux en faire. Tout dépend du contexte. Si tu utilises SYSTABLE en JDBC par exemple, c'est la pelle à clous, parce qu'il y a nettement plus adapté. Si par contre tu es sur un client SQLDev, ce n'est pas sale.