structure de données: stocker/manipuler 168 bits

Version imprimable

22/03/2013, 12h25
alex181

structure de données: stocker/manipuler 168 bits

bonjour,

Je m'interroge sur la manière de représenter 168 valeurs binaires (c'est un planning hebdomadaire, heure par heure, donc 24x7=168)
-dans le programme (C#)
-en base de données (SQL Server)

Au niveau du programme, graphiquement, ca va prendre la forme d'un tableau de 7 lignes et 24 colonnes avec pour chaque cellule 2 valeurs possibles (on va dire 2 couleurs qui permutent comme un interrupteur).

J'aurais besoin classiquement d'une méthode pour lire le tableau et une autre pour écrire.

Pour le stockage en BDD, on pourrait utiliser une string de 168 caractères: "0111100010111...01011"

ou bien la même chose avec 21 octets en hexa:
"08 1F 7C 9D...FF"

Pour la manipulation des données en C#, un tableau de booléen ?

Comment feriez-vous ?
22/03/2013, 13h36
Bluedeep

Citation:

Envoyé par alex181

Pour le stockage en BDD, on pourrait utiliser une string de 168 caractères: "0111100010111...01011"

Je m'interroge sur la pertinence de stocker une seule colonne d'une seule ligne un planning complet. Cela va impliquer des complications de mise à jour et de requétage : si je veux savoir si le lundi 17h est libre il faut examiner le planning complet et il sera extrémement difficile de faire des requêtes SQL du type "donne moi la liste des gus (des terrains de tennis, des bilboquet, etc ....) disponibles mardi de 14 à 18h".

Bref, ce n'est pas du tout du tout l'option que je prendrais. (à voir en fonction du contexte fonctionnel néanmoins).

Citation:

Pour la manipulation des données en C#, un tableau de booléen ?

Ca fait en effet parfaitement l'affaire, sauf si tu as des contraintes mémoires importantes (du type garder le planning de tous les fonctionnaires chinois en mémoire :mrgreen:).
26/03/2013, 22h10
alex181

Effectivement la remarque "une seule colonne, une seule ligne" est pertinente. :ccool:

Le fonctionnel n'est pas encore très clair, mais il me semble que ce "planning" sera simplement stocké d'un seul bloc mais que son contenu ne sera pas vraiment exploité (donc pas de requetage), d'où mon approche "monolithique" :P
26/03/2013, 22h54
Bluedeep

Citation:

Envoyé par alex181

Le fonctionnel n'est pas encore très clair, mais il me semble que ce "planning" sera simplement stocké d'un seul bloc mais que son contenu ne sera pas vraiment exploité (donc pas de requetage), d'où mon approche "monolithique" :P

Et le jour où une évolution de l'application est décidé et qu'il est exploité, ce sera un enfer pour renormaliser la base.

Avec l'habitude, on apprend justement à anticiper ces cas là, et en particulier au niveau du design de base de données. (refondre un code, c'est moins impactant que de refondre un modèle de données).
27/03/2013, 22h00
alex181

C'est vrai que réaliser une évolution plus tard risque d'être assez compliqué.
Après, il faut voir si une solution plus évolutive ne complique pas trop les choses aujourd'hui (peut-être pour rien...attention à YAGNI)

En y réfléchissant rapidement, on pourrait stocker un planning dans une ligne d'une table composée des colonnes:

-une colonne ID
-une colonne avec 14 valeurs possibles représentant les demi-journées de la semaine (lundi matin, lundi après-midi...dimanche après-midi)
-12 colonnes pour stocker la valeur de chaque heure

Une autre idée ?
27/03/2013, 22h23
morgand

Bonjour à tous,

Je pense que ta solution complique beaucoup plus que de faire une base de données structurées. Que se soit en terme de SQL, manipulation de la data, etc.

Professionnellement, je travail sur un moyen de stockage dans des fichiers Binaires, car nous avons des problématiques de performances en lecture qui sont extrêmes. Mais je peux te dire que travailler dessus représente une charge de travail beaucoup plus conséquente que de travailler via un SGBD.

Pour ta dernière solution, je pense que tu devrais regardes les solutions de planning que tu peux trouver sur internet car je pense que (personnellement) que tout enregistrer sur une ligne ne sera très bon niveau maintenance, redondance, etc.

Je pense que tu devrais mettre à plat le besoin fonctionnel puis ensuite réfléchir (toi en tant que technique) à la solution technique.
05/04/2013, 02h40
chamamo
Je ne comprend pas le besoin d'enregistrer sous forme d'heures et en une seule ligne, imagine qu'on te demande ce qui est disponible le lundi de 17h45 à 18h tu fais comment? tu stock les quarts d'heure? et ce qui est disponible de 17h55 à 18h?

c'est l'enfer ta solution, on ne réfléchit pas après avoir développer mais avant.

Il faudrait que tu liste ce qui peut se passer durant la semaine, par type d'événement:

exemple: durant la semaine je peux avoir des RDV (TableRDV), des appels à passer (TableAppels)...

et chaque événement à une date début et date fin (comme ça on n'est pas limité aux heures comme tu proposes.

donc pour résumer:

TableRDV(id, date_debut, date_fin)
TableAppels(id, date_debut, date_fin)

je peux savoir la disponibilité le vendredi 5 avril 2013 de 17h à 18h

je fais une requête pour savoir si je n'ai pas de RDV
Code:

1 2 SELECT * FROM TableRDV WHERE (date_debut>'05/04/2013 17:00' AND date_debut<'05/04/2013 18:00') OR (date_fin>'05/04/2013 17:00' AND date_fin<'05/04/2013 18:00')
si la requête me retourne quelque chose donc pas dispo (3 cas possibles, rdv entre 17h15 et 18h, RDV entre 16h et 17h30, RDV entre 17h45 et 19h)

je m'arrête la

si ça retourne rien je fais la même chose sur la table TableAppels
05/04/2013, 08h30
alex181

Je suis d'accord avec vos remarques "dans le cas général".
En fait, j'ai surement mal expliqué ma situation.
D'ailleurs j'ai eu entre temps confirmation qu'il n'y a pas de requêtage à faire (en gros, cette donnée sera juste enregistrée/puis chargée).
Je ne suis pas sourd et reste d'accord qu'on peut quand même le prévoir.

Vous avez peut-être un programmateur de chauffage à la maison? Il faut indiquer pour chaque jour les heures de "confort" et les heures de "réduit". Et ben c'est exactement ça que je dois modéliser.

Donc déjà, c'est certain, on considère seulement des heures entières (pas de quart d'heures, de 17:55...etc).
05/04/2013, 09h31
sisqo60

Bonjour tout le monde,

Je serais moins tranché que vous. Je prend le rôle de l'avocat du "diable" ;)
Je suis malgré tout assez d'accord avec vous sur la complexité engendrée et l'in-maintenabilité de cette solution. Cela dit, je pense que ce n'est pas réellement une mauvaise option. Tout dépend de la manière dont il modélise sa classe ou sa structure. S'il cache cette complexité derrière des méthodes pertinentes, ça peut donner certes une classe imbitable (sauf si le code est bien découpé, bien commenté, on aurait une classe un peu moins barbare ;) ), mais à l'utilisation cela pourrait être tout aussi simple qu'une autre modélisation plus "objet".

Fini mon boulot d'avocat du diable, maintenant, passons aux choses sérieuses :)

Citation:

Au niveau du programme, graphiquement, ca va prendre la forme d'un tableau de 7 lignes et 24 colonnes avec pour chaque cellule 2 valeurs possibles (on va dire 2 couleurs qui permutent comme un interrupteur).

J'aurais besoin classiquement d'une méthode pour lire le tableau et une autre pour écrire.

Tu l'as dit toi même, un tableau à 2 dimensions [24, 7] ou [7, 24] sera plus simple à représenter et à manipuler.

De plus, pour être plus à même de te répondre de manière pertinente, as-tu des contraintes qui pourraient t'empêcher d'avoir une modélisation plus standard?
05/04/2013, 11h40
chamamo

Dans ce cas, moi j'opterai pour un tableau de deux colonnes
- IdHeure : identifiant de l'heure 1,2,.... 7*24
- Dispo: valeur bool

comme ça c'est plus facile pour moi de chercher
exemple: c'est dispo le mardi à 17?

SELECT dispo from maTable where IdHeure=24+17 (24 car c'est le deuxième jour de la semaine, 17 veut dire 17h)