Ontwerp debat:wat is goeie maniere te stoor en manipuleer weergawes voorwerpe?[gesluit]

Question

Ek is doelbewus verlaat hierdie baie vaag op die eerste.Ek is op soek vir bespreking en kwessies wat belangrik is meer as wat ek is op soek vir'n harde antwoorde.

Ek is in die middel van die ontwerp van'n app wat beteken iets soos portefeulje bestuur.Die ontwerp ek het so ver is

• Probleem:'n probleem wat opgelos moet word
• Oplossing:'n voorgestelde oplossing vir een of meer probleme
• Verhouding:'n verhouding tussen twee probleme, twee oplossings, of'n probleem en'n oplossing.Verder afgebreek in:
  • Ouer-kind - 'n soort van kategorisering / boom hiërargie
  • Oorvleuel - die mate waarin twee oplossings of twee probleme regtig adres van die dieselfde konsep
  • Adresse - die mate waarin'n probleem adresse'n oplossing

My vraag is oor die tydelike aard van hierdie dinge.Probleme opduik, dan vervaag.Oplossings het'n verwagte resolusie datum, maar dit kan verander word soos hulle ontwikkel.Die graad van'n verhouding kan verander met verloop van tyd as die probleme en oplossings te ontwikkel.

So, die vraag:wat is die beste ontwerp vir weergawes van hierdie dinge, sodat ek kan kry beide die huidige en'n historiese perspektief van my portefeulje?

Later:miskien moet ek maak dit'n meer spesifieke vraag, al @Eric Baard se antwoord is die moeite werd'n up.

Ek het oorweeg drie databasis ontwerpe.Ek sal genoeg van elk te wys hul nadele.My vraag is:wat om te kies, of kan jy dink aan iets beter?

1:Probleme (en afsonderlik, Oplossings) is self-referensiële in weergawes.

table problems
  int id | string name | text description | datetime created_at | int previous_version_id

  foreign key previous_version_id -> problems.id

Dit is problematies, want elke keer as ek wil'n nuwe weergawe, ek het om te dupliseer die hele ry, insluitend dat die lang description kolom.

2:Skep'n nuwe Verhouding tipe:Weergawe.

table problems
  int id | string name | text description | datetime created_at

Dit is eenvoudig beweeg die verhouding van die Probleme en Oplossings tafels in die Verhoudings tafel.Dieselfde duplisering probleem, maar miskien'n bietjie "skoner" sedert ek het reeds'n abstrakte Verhouding konsep.

3:Gebruik'n meer Ondermyning-agtige struktuur;skuif al die Probleem en Oplossing eienskappe in'n aparte tafel en hulle weergawe.

table problems
  int id

table attributes
  int id | int thing_id | string thing_type | string name | string value | datetime created_at | int previous_version_id

  foreign key (thing_id, thing_type) -> problems.id or solutions.id
  foreign key previous_version_id -> attributes.id

Dit beteken dat om te laai die huidige weergawe van'n Probleem of Oplossing wat ek het om te haal al die weergawes van die eienskap, sorteer hulle deur die datum en gebruik dan die mees onlangse.Wat dalk nie vreeslik.Wat lyk regtig sleg vir my is dat ek kan nie tik-check hierdie eienskappe in die databasis.Dat value kolom het om vry te wees-teks.Ek kan die name kolom'n verwysing in'n aparte attribute_names tafel wat'n type kolom, maar dit beteken nie krag die korrekte tipe in die attributes tafel.

later nog steeds:reaksie op @Eric Baard se kommentaar oor die multi-tafel buitelandse sleutels:

Helaas, wat ek beskryf het, is eenvoudig:daar is net twee soorte van Dinge (Probleme en Oplossings).Ek het eintlik het ongeveer 9 of 10 verskillende soorte van Dinge, so ek het 9 of 10 kolomme van buitelandse sleutels onder jou strategie.Ek wou om te gebruik enkel-tafel erfenis, maar die Dinge het so min in gemeen dat dit sou wees baie verkwistende te doen, kombineer hulle in een tafel.

Answer 1

Hmm, klink soort van soos hierdie site...

So ver As'n databasis ontwerp sou gaan, 'n weergawes stelsel soort van soos SVN, waar jy nooit eintlik doen enige updates, net insetsels (met'n weergawe nommer) wanneer dinge verander, kan wees wat jy nodig het.Dit is die sogenaamde MVCC, Multi-Waarde gelyktydigheidsbeheer.'n wiki is'n ander goeie voorbeeld van hierdie.

Answer 2

@Gaius

foreign key (thing_id, thing_type) -> problems.id or solutions.id

Wees versigtig met hierdie soort van "multi" vreemde sleutels. My ondervinding het getoon dat navraag prestasie ly dramaties wanneer jou aansluit toestand moet die tipe check voor uitzoeken wat tafel aan te sluit op. Dit lyk nie so elegant maar waarvoor geen nul mag

problem_id and solution_id 

sal baie beter werk.

Natuurlik sal navraag prestasie ook ly met 'n MVCC ontwerp wanneer jy die tjek toe te voeg tot die jongste weergawe van 'n rekord kry. Die nadeel is dat jy nooit hoef te bekommer oor die twis met updates.

Answer 3

Hoe dink jy oor weet:

tafel probleme
  int id | string naam | teks beskrywing | DATETIME created_at

tafel problems_revisions
  int hersiening | int id | string naam | teks beskrywing | DATETIME created_at
  vreemde sleutel id -> problems.id

Voor updates jy 'n addisionele insetsel uit te voer in die hersiening tafel. Hierdie bykomende insetsel is vinnig, maar dit is wat jy hoef te betaal vir

1. doeltreffende toegang tot die huidige weergawe - kies probleme soos gewoonlik
2. 'n skedule wat is intuïtief en naby aan die werklikheid wat jy wil om 'n model
3. sluit tussen tafels in jou skedule hou doeltreffende
4. die gebruik van 'n hersiening aantal per business transaksie wat jy kan doen weergawes oor tafel rekords soos SVN doen oor lêers.

Answer 4

Ek dink daar is

Opsie 4: die baster

Skuif die algemene ding skryf in 'n enkel-erfenis tafel, en voeg dan 'n custom_attributes tafel. Dit maak buitelandse-sleutels eenvoudiger, verminder duplisering, en laat buigsaamheid. Dit maak nie die probleme van tipe-veiligheid vir die addisionele eienskappe op te los. Dit voeg ook 'n bietjie kompleksiteit want daar is twee maniere om 'n ding om 'n eienskap het nou.

As description en ander groot velde bly in die tafel nie, alhoewel dit ook nie los die duplisering-ruimte probleem.

table things
  int id | int type | string name | text description | datetime created_at | other common fields...
  foreign key type -> thing_types.id

table custom_attributes
  int id | int thing_id | string name | string value
  foreign key thing_id -> things.id

Answer 5

Dit is 'n goeie idee om 'n datastruktuur wat algemene vrae wat jy vra van die model maklik om te beantwoord maak kies. Dit is heel waarskynlik dat jy belangstel in die huidige posisie meeste van die tyd is. By geleentheid, sal jy wil om te boor in die geskiedenis vir spesifieke probleme en oplossings.

Ek sou tafels vir probleem, oplossing, en verhouding wat die huidige posisie verteenwoordig het. Daar sal ook 'n problem_history, solution_history, ens tafel wees. Dit sou wees kind tafels van die probleem, maar bevat ook ekstra kolomme vir VersionNumber en EffectiveDate. Die sleutel sal wees (ProblemId, VersionNumber).

As jy 'n probleem op te dateer, sal jy die ou waardes in die problem_history tafel te lê. Tydstip navrae is dus moontlik as jy kan kies uit die problem_history rekord wat geldig is as-op 'n bepaalde datum.

Waar ek hierdie al voorheen gedoen, ek het ook 'n oog op UNION problem en problem_history as dit is soms nuttig in verskeie navrae.

Opsie 1 maak dit moeilik om die huidige situasie te bevraagteken, as al jou historiese data met jou huidige data gemeng in.

Opsie 3 gaan sleg vir navraag prestasie en nare by kode teen as jy sal toegang tot baie rye vir wat moet net 'n eenvoudige navraag te wees.