Bonsoir,
j'ai besoin de modéliser une base avec la problématique suivante :
 
dans un ensemble d'une centaine de numéros distincts , on en sélectionne une trentaine chaque jour (ce nombre est fixe). Chaque sélection doit être sauvegardée dans une table à partir de laquelle on fera des statistiques dessus.
 
Les contraintes concernant cette modélisation sont les suivantes :
1. la trentaine de numéros doivent être différents les uns des autres.
2. on ne fera que des select sur la table concernant les sélections, pas d'update ni de delete.
3. les sélections provenant d'un lot dts, avec possibilité de non respect sur la contrainte 1, je dois vérifier que chaque sélection comporte 30 numéros distincts.
 
Comment pourrais-je modéliser cette base de façon à ce la lecture soit la plus rapide possible sous SqlServer 2000 ?
 
Merci pour vos réponses.

select top 30 numero from latabledesnumeros order by random
 
sauf que je me souviens que c'est un peu plus compliqué, mais dans l'espris, c'est ça. ca résoud ta première contrainte simplement déjà.
pour la seconde... ben voilà...
pour la dernière, j'ai rien pigé.

heu ... c'est pas tout à fait d'une requête dont j'ai besoin mais de modéliser ces intités.
 
1. je vais pas faire une requête sur une table alors que je ne sais pas encore quelles tables je vais créer (c'est le but de ma question).
2. quand je dis pas d'update, ni delete mais uniquement des select c'est pour dire que ça ne pose pas de problème de mettre plein d'index partout pour optimiser les requêtes de sélection (et donc parfois au détriment des insertions et updates).
3. la dernière contrainte, c'était pour savoir ce qu'il fallait mettre comme contraintes sur les tables pour vérifier que les enregistrements insérés sont corrects,  étant donné que les données importées peuvent contenir des erreurs (je les importe via dts, à partir d'un fichier qu'on me fournit).

réexplique, parceque j'ai RIEN compris j'ai l'impression.
 
t'as quoi comme tables ?
tes 100 numéros, ils sont où ? ils servent à quoi ? on doit en faire quoi des 30 ?

pour le 3, une contrainte d'unicité sur les numéros permet de vérifier qu'il n'y a pas de doublons.
mais vu que j'ai toujours pas compris ce que tu fais de ces numéros...

oui, je sais ce que c'est que DTS, mais ce que je ne comprends pas, c'est ce que tu veux faire avec.
 
parceque si tu dois simplement importer des lots de 30 numéros, en vérifiant qu'ils sont systématiquement uniques, c'est tout bête :
 
tu crées une table "numeros" avec un champ unique "numero", qui est PK (et donc unique).
et tu importe bêtement tous tes numéros dedans.
 
si l'unicité ne doit porter que sur les 30 numéros de chaque lots (uniques au sein d'un lot, mais non uniques d'un lot à l'autre), alors dans "numeros", tu ajoutes un champ "lot" qui va contenir un nombre différent pour chaque lot (1, 2, 3, 4, ...) - ou un champ de type date, avec la date du lot, comme tu veux, on s'en fout -, que tu fait participer à la PK (donc unicité sur le coupe "numero,lot" ).
 
et zou.
 
de ce que je comprend de ton schmilblik, c'est simple comme choux.

Sauf que le modèle n'est pas génial pour les performances.
Je créerai une table de lot avec un id comme PK + un champ date associé, et une table de numéros avec un numéro comme PK et une table de jointure entre les 2 qui contiendrait l'association entre les numéros et le numéro de lot.
 
Il y aura 3 tables et non 1 table.
C'est p.e simple comme choux, mais ce que je voulais c'était le meilleur choix possible vis-à-vis des performances.
Ta proposition ne va pas dans ce sens, mais merci quand même ...

Euh... Amuse-toi à faire des tests hein...
 
Parceque 3 tables dont une de correspondance, qui va contenir rigoureusement les mêmes informations que mon unique table, j'ai un peu de mal à concevoir ta notion d'optimisation.
 
A part ça, si tu crois avoir la solution, je me demande bien pourquoi tu postes ta question si ce n'est pour pas tenir compte des réponses qu'on te donne.
 
Enfin bref. Débrouille-toi tout seul, ou alors poste au moins une bonne fois pour toute l'énnoncé de ton problème de TP (parceque c'est tellement biscornu, et t'as l'air tellement hardi que je ne vois que le TP comme explication possible).

pour une fois, je plussoie arjuna

 
Je poste une question pour avoir la meilleure réponse possible, ce qui est loin d'être ta réponse.
 
Tu sais ce que c'est que l'optimisation ?
Le but de ma question était quel modèle ? quels index poser ? clusterded ? non clustered ? en fonction du modèle évidemment ...
 
et toi, tu me sors une requête ... si t'as pas le niveau pour comprendre la question, n'y réponds pas !
 
Vu ton niveau, je me débrouillerai sans toi, mais merci quand même ! ;-)

 
Toi, t'es un mec hardi, tu comprends vite c'est sur ! ;-)

Je crois qu'il a fait de son mieux sur base de tes explications pas très claires. Je me suis moi-même perdu en hypothèses en lisant ce topic.
 

Tu ne sais manifestement pas à qui tu parles!
 

Encore plus fort !
 

Si lui n'a pas le niveau requis, peu de personnes ici l'ont... Ta question vole sans doute bcp trop haut.
 

Ce que je reproche, c'est le ton de sa réponse.
 
Ma démarche était de chercher le meilleur modèle possible, et lui me sort une requête ! et me redemande combien de tables j'ai en base ?
 
Il est décidément trop bon pour se permettre après de répondre avec un ton qui frise le mépris ...
 
Si peu de personnes ici ont le niveau pour répondre, tant pis.
 
Merci quand même !

Et pas seulement ça, manifestement.
 

Il t'a fait une proposition, tu n'en tiens pas compte, il se demande à quoi bon, rien d'étonnant.
Compte tenu de la formulation alambiquée de ta demande initiale...
 

Tu pousses un peu. C'est pas trop son genre. En matière de réponse méprisante, tu t'es pas mal débrouillé.
 

Tu te la joue, hein ? Ne te remets surtout pas en cause. Plusieurs personnes te disent ne pas comprendre ta question, te proposent de reformuler et tu ne prends pas la peine de d'y répondre.

Après m'avoir sorti une requête sur un modèle, et après lui avoir réexpliqué ce que je voulais, il me file une réponse en disant "mets tout ton shmilblik dans une table ! c'est bête comme choux !".
 
Sil se la jouait pas autant, je lui aurais expliqué ce que c'est que des formes normales dans une SGBD.
 
Concernant les optimisations, je ne sais pas à qui je parle ? Lol ! trouves moi un endroit où il parle de clustered index sur des PK et éventuellement de non-clustered index sur d'autres champs si besoin était d'en rajouter ?
 
Allez, on va s'arrêter là.
Je n'ai pas le niveau pour comprendre vos explications, vous êtes trop balèzes ... ;-)
 
Ca ne sert à rien de continuer dans ce sens.
 
Merci quand même pour toutes vos réponses.

KeyTronic > Euh. Y'a un problème quand même là...
 
Hier, je tombe sur ce topic, auquel je comprend vaguement que t'as un problème avec des des numéros dans des tables, rien de concret, aucun élément permettant de comprendre la problématique (avant de songer à la base de données, pense à faire l'analyse du problème, si dans ta tête c'est aussiobscure que dans ton énoncé, tu ne pourras jamais faire un truc correct).
 
Partant sur l'hypothèse que c'est pas un problème de conception (parceque je ne vois pas où il y a la moindre problématique de conception là-dedans...), je me dit que t'as un souci de requête, d'où ma réponse.
 
Ensuite, tu me dit que c'est pas ça. Le ton sur lequel tu me le dit ma fait tiquer, mais bon, après-tout, quand on attends une réponse et qu'on lit quelquechose à côté de la plaque, c'est agaçant, je comprends bien.
 
Je te répond alors hier soir ma façon de voir la modélisation. Entre la merde que tu proposes et ma solution, la mienne est meilleure, si t'arrive pas à comprendre ça, réfléchit un peu plus, franchement, c'est pas compliqué : mon unique table contient rigoureusement les mêmes infos que ta table de correspondance... Alors je fois pas l'intérêt de rajouter les deux autres tables (surtout la table contenant la liste des numéros, c'est total n'importe quoi).
 
Et ce matin, je me réveille la tête dans le paté, et qu'est-ce que je lis ? Que tu m'envoies chier (à ce moment, je te rappelle, j'étais le seul a avoir pris le temps d'essayer de comprendre ta soupe au charabia et tenté d'y apporter une réponse, ça mérite au moins le respect), en me sortant que tu as LA solution (ben alors pourquoi tu poses une question ?) et qu'elle est donc forcément meilleur que la mienne, que tu n'as manifestement même pas pris le temps de lire complètement (ou comprendre).
 
Alors ouais, excuse-moi du peu, mais j'avais des raisons de te répondre sèchement, tout comme je le refais maintenant.

t'es con ou quoi ?
dans ta base, t'as besoin de deux champs :
- numéro
- lot (que ce soit un numéro de lot, une date, ou ce que tu veux, on s'en fout)
 
Je te dis de les mettre dans une table, et faire une PK dessus.
 
Si tu connaissait un peu SQL Server 2000, tu saurais qu'une PK est par défaut indexée en cluster.
Ensuite, vu que t'as ça comme champs dans ta table (et même ta base), je vois pas l'intérêt de faire d'autres index... Si ?
 
PS: et pour définir des index, il faut encore savoir à quoi sert à la base, on ne met pas les mêmes index selon les informations recherchées, et encore moins sur la façon de les rechercher...
 
Bref, avant de me prendre pour un con, fait le ménage devant ta porte stp.

 
Et le titre "Modélisation d'une base avec accès optimisé en lecture"
 

pour le con, je crois que tu réponds parfaitement à la définition...
 
Mais si tu peux rester poli, ce serait encore mieux ... ;-)

Brave garçon, faut savoir se contrôler ...

Ben déjà, ce titre ne veux rien dire. Alors à partir de là...
 
J'essaie de rester poli, mais au bout d'un moment, ça devient difficile. Reconnais au moins tes erreurs et ton incompétence au lieu de me (nous) prendre pour de la merde. Si t'étais un génie, tu n'aurais pas besoin de conseil.
Quant à ta base, tu pourras rien optimiser pour quoi que ce soit, si tu fais comme je te dis, tu ne pourras pas faire mieu, point.
 
Je me demande bien pourquoi je me fatigue encore à te répondre.

Tu as raison, ne te fatigues pas.
Si je pose des questions, c'est parce-que je ne me prends pas pour un crack.
 
Mais quand on sort une requête sur un besoin de modélisation, et sur un ton méprisant, ben c'est pas la peine non plus.

 

 
D'autres questions ?

lol, déjà, la requête, je n'en ai pas reparlé depuis mon premier post. ensuite, je n'ai pas été méprisant jusqu'à ce que tu me sortes ta science infuse sur des domaines que tu ne maîtrise visiblement pas du tout (que ce soit la modélisation - la dénormalisation, tu connais ? - ou SQL Server)
 
bref, arrête de tout mélanger, et ne t'étonnes pas si je suis le seul a bien avoir voulu perdre mon temps à te répondre. tu ne risques pas d'avoir d'autres réponses maintenant.
 
pour info, si même gizmo, avec qui j'ai un léger différent ancien et permanant, s'est arraché la bouche à dire qu'il était d'accord avec moi, je doute qu'une seule autre personne de ce forum ne vienne perdre son temps ici.

Outre les fadas dans mon genre qui viennent jeter de l'huile sur le feu et compter les points. En toute impartialité
 
Parle-nous de ce différend avec gizmo. Il est peut-être temps de vous réconcilier.    

c'est pas grave, vu la qualité des réponses et le ton utilisé, je ne perds rien.

chais pus moi
 
j'avais du dire une énormité en C++ ou Java, ou même pire, dire que le C et le C++ c'était pareil
 
ça c'est des truc que je maîtrise pas du tout, et je déteste ces langages, donc je fais aucun effort
 
mais c'est peut-être autrechose, je sais plus du tout (lui non plus je pense)

Apres lecture du probleme, la solution d'Arjuna est bonne.
 
Moi je propose afin de reduire encore le nombre d'enregistrements dans la table de consultation courante la solution suivante.
 
Une premiere table avec ton perimetre (les 100 enregistrements de depart)
Une seconde table où l'on retrouvera uniquement la selection du jour (les 30 enregistrements differents)
Une troisieme table historique avec la selection du jour associé à la date. Elle te serivra pour les stats.
 
Apres pour l'alimentation des tables, tu dois savoir faire.