Re: Chacun dans son dossier, comment feriez-vous ?

On 16 mars 2011, at 12:09, Hervé Agnoux wrote:

> Le mercredi 16 mars 2011, Jean-Baptiste BRIAUD -- Novlog a écrit :
>> 
>> Je ne changerais pas OpenJPA, pour plein de raisons, mais surtout pour la
>> raison suivante. Nous faisons un usage intensif des FetchPlan, concept que
>> l'on ne retrouve malheureusement pas dans Hibernate.
>> 
>> Quand aux données, c'est une contrainte, çà doit être des tables dans une
>> base de données relationnelles classique. Je vais jeter un oeil à JCR mais
>> j'ai l'impression que c'est un stockage à part, pas dans la base elle
>> même.
> 
> Moi aussi je trouve que JCR correspond bien au besoin que tu as exprimé plus 
> haut. Toutefois j'ai de plus en plus tendance à ranger le JCR dans la 
> catégorie des technos super bien mais qui percent pas pour des raisons qui 
> m'échappent. 
> 
> Je l'utilise, et ça marche impec ; comprends pas pourquoi les autres 
> l'utilisent pas.
> 
> Au niveau stockage, c'est en standard dans une base de donnée derby. Les 
> grosses données sont dans un stockage à part - qui peut très bien être du 
> derby aussi.Tu peux faire dans n'importe quelle autre base de données, ou dans 
> des fichiers.
> 
Je ne dis pas que JCR est inadéquat, je dis que je ne peux pas le choisir.
Mieux, la solution doit utiliser OpenJPA et pas une autre techno.
Je dois donc me débrouiller avec OpenJPA et une base de données classique.

De plus, mes données ne sont pas semi-structurées, mais très structurées et bien classiques.
Seul les permissions sont a ajouter "par dessus".

Pour clarifier ce qui est hiérarchique : pas les données, pas les permissions mais éventuellement les utilisateurs.

Il s'agit donc d'appliquer des permissions fines (elles doivent pouvoir porter sur les tuples) à des données.
Les permissions sont associées aux utilisateurs qui eux, mais eux seulement sont susceptible d'être hiérarchique.

Quant au volume de données, cela dépends bien sur des tables, mais parions sur quelques tables assez volumineuses genre plusieurs millions de lignes.
Or plusieurs millions de lignes pour quelques tables, c'est le cas nominal pour une base de données.
D'où l'idée d'utiliser la base pour filter les données avec les permissions fines.
Pour rappel, les données sont dors et déjà manipulées, filtrée, CRUDées et la base fait bien son boulot.
Je ne vois donc pas bien pourquoi un filtre de plus, les permissions, serait fatal ... même si j'entends bien que cela aura un coût sur les perfs : "rien ne se perds, rien ne crée, tout se transforme" :-)

N'hésitez pas à me contredire !

D'où il ressort de cette logique : une table de permission pour une table de données à gérer finement (ce qui n'est pas le cas de toutes les tables, heureusement).