Vaikuttaa siltä, ​​että sinulla (ja/tai yritykselläsi) on perustavanlaatuinen väärinkäsitys siitä, minkä sukupuun oletetaan olevan.

Selvennetään, että työskentelen myös yrityksessä, jonka portfoliossa on (yhtenä tuotteena) sukupuu ja olemme kamppaillut vastaavien ongelmien kanssa.

Ongelma meidän tapauksessamme ja oletan myös sinun tapauksessasi johtuvan GEDCOM-muodosta, joka on erittäin mielissään siitä, millainen perheen tulisi olla. Tämä muoto sisältää kuitenkin vakavia väärinkäsityksiä siitä, miltä sukupuu todella näyttää.

GEDCOMilla on monia ongelmia, kuten yhteensopimattomuus samaa sukupuolta olevien suhteiden kanssa, insesti jne. Mitä tosielämässä tapahtuu useammin kuin uskotkaan (varsinkin kun palataan ajassa taaksepäin 1700-1800).

Olemme mallintaneet sukupuumme sen mukaan, mitä todellisessa maailmassa tapahtuu: Tapahtumat (esimerkiksi syntymät, häät, kihlaukset, liitot, kuolemat, adoptiot jne.). Emme aseta näille mitään rajoituksia, paitsi loogisesti mahdottomia (esim. ei voi olla oma vanhempi, ihmissuhteissa tarvitaan kaksi henkilöä jne...)

Validointien puute antaa meille "todellisemman maailman", yksinkertaisemman ja joustavamman ratkaisun.

Mitä tulee tähän erityistapaukseen, ehdotan väitteiden poistamista, koska ne eivät päde yleisesti.

Ongelmien näyttämiseksi (jotka syntyvät) suosittelen piirtämään saman solmun niin monta kertaa kuin tarvitaan, vihjaten päällekkäisyyteen sytyttämällä kaikki kopiot, kun valitaan yksi niistä.

Rentoudu väitteesi.

Ei muuttamalla sääntöjä, joista on todennäköisesti erittäin paljon apua 99,9 %:lle asiakkaistasi tietojen syöttämisessä tapahtuneiden virheiden havaitsemisessa.

Sen sijaan muuta se virheestä "ei voi lisätä suhdetta" varoitukseksi "lisää silti".

Tässä on sukupuiden ongelma: ne eivät ole puita. Ne ovat suunnattuja asyklisiä kuvaajia tai DAG:ita. Jos ymmärrän ihmisen lisääntymisbiologian periaatteet oikein, kiertoja ei tule olemaan.

Tietääkseni kristitytkin hyväksyvät avioliitot (ja siten lapset) serkkujen välillä, mikä tekee sukupuusta perheen DAG:n.

Tarinan moraali on: valitse oikeat tietorakenteet.

Luulen, että sinulla on jokin arvo, joka yksilöi yksilöllisesti henkilön, johon voit perustaa shekkisi.

Tämä on hankala tapaus. Olettaen, että haluat pitää rakenteen puuna, ehdotan tätä:

Oletetaan tämä: A on lapsia oman tyttärensä kanssa.

A lisää itsensä ohjelmaan nimellä A ja B. Kun kerran isän roolissa, kutsutaan sitä poikaystäväksi.

Lisää is_same_for_out()-funktio, joka kertoo ohjelmasi tuotoksia tuottavalle osalle, että kaikkien linkkien, jotka menevät osoitteeseen B, tulee mennä osoitteeseen A tietojen esittämisen yhteydessä.

Tämä tekee käyttäjälle hieman ylimääräistä työtä, mutta luulen, että IT olisi suhteellisen helppo toteuttaa ja ylläpitää.

Sen pohjalta voit kehittää koodin synkronointia A ja B epäjohdonmukaisuuksien välttämiseksi.

Tämä ratkaisu ei varmasti ole täydellinen, mutta se on ensimmäinen lähestymistapa.

Keskity siihen, mikä todella tuottaa ohjelmistollesi arvoa. Onko sen toimimiseen YHDELLÄ kuluttajalle käytetty aika lisenssin hinnan arvoinen? Todennäköisesti ei.

Suosittelen sinua pyytämään anteeksi tältä asiakkaalta, kertomaan hänelle, että hänen tilanteensa ei sovellu ohjelmistollesi, ja myöntämään hänelle hyvitys.

Sinun olisi pitänyt perustaa Atreides-perhe (joko moderni, Dyyni tai muinainen, Oidipus Rex) testaustapauksena. Et löydä vikoja käyttämällä testattua dataa.

Tämä on yksi syistä, miksi kielillä, kuten "Go", ei ole väitteitä. Niitä käytetään käsittelemään tapauksia, joita et luultavasti ajatellut liian usein. Sinun tulee väittää vain mahdotonta, ei vain epätodennäköistä. Jälkimmäisen tekeminen antaa väitteille huonon maineen. Aina kun kirjoitat assert(, kävele pois kymmeneksi minuutiksi ja todella ajattele sitä.

Erityisen huolestuttavassa tapauksessanne on sekä ajateltavissa että kauhistuttavaa, että tällainen väite olisi harhaanjohtava harvoissa mutta mahdollisissa olosuhteissa. Siksi käsittele sitä sovelluksessasi, jos vain sanot "Tätä ohjelmistoa ei ole suunniteltu käsittelemään esittämääsi skenaariota".

On järkevää väittää, että isoisoisäsi on mahdoton isäsi.

Jos olisin työskennellyt testausyrityksessä, joka oli palkattu testaamaan ohjelmistoasi, olisin tietysti esittänyt tämän skenaarion. Miksi? Jokainen nuori mutta älykäs "käyttäjä" tekee täsmälleen saman asian ja nauttii tuloksena olevasta "virheraportista".

Inhoan kommentoida näin sotkuista tilannetta, mutta helpoin tapa olla muuttamatta kaikkia invarianttejasi on luoda kuvaajaasi haamuvertex, joka toimii välityspalvelimena takaisin insesti-isälle.

Olen siis tehnyt jonkin verran työtä sukupuuohjelmiston parissa. Luulen, että ongelma, jota yrität ratkaista, on se, että sinun täytyy pystyä kävelemään puuta joutumatta äärettömiin silmukoihin - toisin sanoen puun on oltava asyklinen.

Näyttää kuitenkin siltä, ​​että väität, että henkilön ja yhden hänen esi-isänsä välillä on vain yksi polku. Se takaa, että jaksoja ei ole, mutta se on liian tiukka. Biologisesti katsottuna jälkeläinen on suunnattu asyklinen kaavio (DAG). Tapaus, joka sinulla on, on varmasti rappeutunut tapaus, mutta tällaista tapahtuu koko ajan suuremmilla puilla.

Jos esimerkiksi katsot 2^n esi-isäsi, jotka sinulla on sukupolvella n, jos päällekkäisyyttä ei olisi, sinulla olisi enemmän esi-isiä vuonna 1000 jKr. kuin ihmisiä oli elossa. Joten päällekkäisyyksiä täytyy olla.

Saatat kuitenkin myös yleensä virheellisiä syklejä, vain huonoja tietoja. Jos kuljet puun poikki, syklit on käsiteltävä. Voit tehdä tämän jokaisessa yksittäisessä algoritmissa tai latauksen aikana. Tein sen kuormituksella.

Todellisten syklien löytäminen puusta voidaan tehdä muutamalla tavalla. Väärä tapa on merkitä jokainen esi-isä tietystä yksilöstä, ja jos kuljetettaessa henkilö, johon aiot astua, on jo merkitty, katkaise linkki. Tämä katkaisee mahdollisesti tarkat suhteet. Oikea tapa tehdä se on aloittaa jokaisesta yksilöstä ja merkitä kullekin esi-isälle polku kyseiseen yksilöön. Jos uusi polku sisältää nykyisen polun alipolkuna, se on sykli, ja sen pitäisi olla rikki. Voit tallentaa polut vektorimuodossa bool> (MFMF, MFFFMF jne.), mikä tekee vertailusta ja tallentamisesta erittäin nopeaa.

On olemassa muutamia muita tapoja havaita jaksoja, kuten lähettää kaksi iteraattoria ja nähdä, törmäävätkö ne koskaan osajoukkotestiin, mutta päädyin käyttämään paikallista tallennusmenetelmää.

Huomaa myös, että sinun ei tarvitse varsinaisesti katkaista linkkiä, voit vain muuttaa sen tavallisesta linkistä "heikkoksi" linkiksi, jota jotkin algoritmeistasi eivät seuraa. Sinun kannattaa myös olla varovainen valitessasi, mikä linkki merkitään heikoksi. joskus voi selvittää missä kierteen pitäisi katketa ​​katsomalla syntymäaikatietoja, mutta usein ei saa selvää, koska dataa puuttuu niin paljon.

Toinen näennäisesti vakava vastaus tyhmään kysymykseen:

Todellinen vastaus on käyttää asianmukaista tietorakennetta. Ihmisen sukututkimusta ei voida täysin ilmaista käyttämällä puhdasta puuta, jossa ei ole sykliä. Sinun pitäisi käyttää jonkinlaista kaaviota. Keskustele myös antropologin kanssa ennen kuin jatkat tätä asiaa, koska on monia muita paikkoja, joissa samanlaisia ​​virheitä voidaan tehdä yritettäessä mallintaa sukututkimusta, jopa yksinkertaisimmassa tapauksessa "länsipatriarkaalisessa yksiavioisessa avioliitossa".

Vaikka haluaisimme jättää huomioimatta paikallisesti tabusuhteet, kuten täällä on käsitelty, on olemassa monia täysin laillisia ja täysin odottamattomia tapoja tuoda syklit sukupuuhun.

Esimerkki: http://en.wikipedia.org/wiki/Cusin_marriage

Pohjimmiltaan serkkujen avioliitto ei ole vain yleinen ja odotettu, vaan se on syy, miksi ihmiset ovat muuttuneet tuhansista pienistä perheryhmistä maailmanlaajuiseksi 6 miljardin väestöksi. Se ei voi toimia millään muulla tavalla.

Sukututkimuksen, perheen ja sukulinjan suhteen on todella vähän universaaleja. Melkein kaikki tiukat oletukset normeista, jotka viittaavat siihen, kuka täti voi olla tai kuka voi mennä naimisiin kenen kanssa tai miten lapset laillistetaan perintötarkoituksessa, voi järkyttyä jostain poikkeuksesta jossain maailmassa tai historiassa.

Mahdolliset oikeudelliset vaikutukset sivuun, näyttää varmasti siltä, ​​että sinun on kohdeltava sukupuun "solmua" edeltäjä-henkilönä sen sijaan, että olettaisit, että solmu voi olla yksi ja ainoa henkilö.

Pyydä puusolmua sisältämään henkilö sekä seuraajat - ja sitten voit saada toisen solmun syvemmälle puussa, joka sisältää saman henkilön eri seuraajilla.

Muutamat vastaukset ovat osoittaneet tapoja säilyttää väitteet/invariantit, mutta tämä vaikuttaa väitteiden/invarianttien väärinkäytöltä. Väitteillä on tarkoitus varmistaa, että jokin, jonka pitäisi olla totta, on totta, ja invarianttien on varmistettava, että jokin, jonka ei pitäisi muuttua, ei muutu.

Väität tässä, että insestisuhteita ei ole olemassa. Selvästikin niitä on olemassa, joten väitteesi on virheellinen. Voit kiertää tämän väitteen, mutta todellinen vika on itse väitteessä. Väite on poistettava.

Sukupuussasi tulisi käyttää suunnattuja suhteita. Näin sinulla ei ole kiertoa.

Sukutieto on syklistä eivätkä mahdu asykliseen kuvaajaan, joten jos sinulla on väitteitä syklejä vastaan, sinun tulee poistaa ne.

Tapa käsitellä tämä näkymässä luomatta mukautettua näkymää on käsitellä syklistä ylätasoa "haamupäänä". Toisin sanoen, kun henkilö on sekä isä että isoisä samalle henkilölle, isoisolmu näytetään normaalisti, mutta isäsolmu muunnetaan "haamu"-solmuksi, jolla on yksinkertainen tunniste, kuten ("katso isoisä") ) ja osoittaa isoisää.

Laskelmien tekemiseksi sinun on ehkä parannettava logiikkaasi syklisten kuvaajien käsittelemiseksi, jotta solmussa ei käydä useammin kuin kerran, jos sykli on olemassa.

Tärkeintä on avoid creating a problem, joten uskon, että sinun tulee käyttää suoraa suhdetta välttääksesi kiertokulkua.

Kuten @markmywords sanoi, #sisältää "fritzl.h".

Lopuksi minun on sanottava recheck your data structure. Ehkä siellä on jotain vialla (ehkä kaksisuuntainen linkitetty luettelo ratkaisee ongelmasi).

Väitteet eivät kestä todellisuutta

Yleensä väitteet eivät selviä kontaktista todellisen maailman datan kanssa. Se on osa ohjelmistosuunnitteluprosessia päättää, mitä tietoja haluat käsitellä ja mitkä ovat soveltamisalan ulkopuolella.

Sykliset perhekaaviot

Suku "puista" (itse asiassa ne ovat täydellisiä kaavioita, mukaan lukien syklit), on mukava anekdootti:

Menin naimisiin lesken kanssa, jolla oli aikuinen tytär. Isäni, joka vieraili meillä usein, rakastui tyttärepuoleni ja meni naimisiin hänen kanssaan. Tämän seurauksena isästäni tuli poikani ja tyttärestäni äitini. Jonkin ajan kuluttua annoin vaimolleni pojan, joka oli isäni veli, ja setäni. Isäni vaimo (joka on myös tyttäreni ja äitini) sai pojan. Tuloksena sain veljen ja pojanpojan samassa henkilössä. Vaimoni on nyt isoäitini, koska hän on äitini äiti. Olen siis vaimoni aviomies ja samalla vaimoni pojanpoika. Toisin sanoen olen oman isoisäni.

Asiat muuttuvat vieläkin kummallisemmiksi, kun otat huomioon korvikkeet tai "sumean isyyden".

Kuinka käsitellä sitä

Määritä syklit soveltamisalan ulkopuolelle

Voit päättää, että ohjelmistosi ei käsittele tällaisia ​​harvinaisia ​​tapauksia. Jos tällainen tapaus ilmenee, käyttäjän tulee käyttää toista tuotetta. Tämä tekee yleisempien tapausten käsittelystä paljon vankempaa, koska voit säilyttää enemmän väitteitä ja yksinkertaisemman tietomallin.

Lisää tässä tapauksessa ohjelmistoosi hyviä tuonti- ja vientiominaisuuksia, jotta käyttäjä voi tarvittaessa helposti siirtyä toiseen tuotteeseen.

Salli manuaaliset suhteet

Voit antaa käyttäjän lisätä manuaalisia suhteita. Nämä suhteet eivät ole "ensiluokan kansalaisia", eli ohjelmisto ottaa ne sellaisenaan, ei tarkista eikä käsittele niitä päätietomallissa.

Käyttäjä voi sitten käsitellä harvinaisia ​​tapauksia käsin. Tietomallisi pysyy silti melko yksinkertaisena ja väitteesi säilyvät.

Ole varovainen manuaalisten suhteiden kanssa. On houkutus tehdä niistä täysin konfiguroitavissa ja luoda siten täysin konfiguroitavissa oleva tietomalli. Tämä ei toimi: Ohjelmistosi ei skaalaudu, saat outoja bugeja ja lopulta käyttöliittymä muuttuu käyttökelvottomaksi. Tätä estomallia kutsutaan "pehmeäksi koodaukseksi" ja "Päivittäinen WTF" on täynnä esimerkkejä tästä.

Tee tietomallistasi joustavampi, ohita väitteet, testaa invariantteja

Viimeinen keino olisi tehdä tietomallistasi joustavampi. Sinun pitäisi ohittaa melkein kaikki väitteet ja perustaa tietomallisi täydelliseen kaavioon. Kuten yllä oleva esimerkki osoittaa, on helposti mahdollista olla oma isoisäsi, joten sinulla voi olla jopa kiertoja.

Tässä tapauksessa sinun tulee testata ohjelmistoasi perusteellisesti. Sinun piti ohittaa melkein kaikki väitteet, joten on olemassa hyvä mahdollisuus lisävirheille.

Käytä testidatan generaattoria tarkistaaksesi epätavalliset testitapaukset. Haskell, Erlang tai C. Javalle/Scalalle on olemassa ScalaCheck ja Nyaya. Yksi testiidea olisi simuloida satunnaista populaatiota, antaa sen risteytyä satunnaisesti, antaa ohjelmiston sitten ensin tuoda ja viedä tulos. Odotuksena olisi, että kaikki lähdön liitännät ovat myös tulossa ja toisinpäin.

Tapausta, jossa ominaisuus pysyy samana, kutsutaan invariantiksi. Tässä tapauksessa invariantti on joukko "romanttisia suhteita" simuloidun populaation yksilöiden välillä. Yritä löytää mahdollisimman paljon invariantteja ja testaa niitä satunnaisesti luoduilla tiedoilla. Invariantit voivat olla toiminnallisia, esim.

• setä pysyy setänä, vaikka siihen lisätään "romanttisia suhteita"
• jokaisella lapsella on vanhempi
• kahden sukupolven väestöllä on vähintään yksi isovanhempi

Tai ne voivat olla teknisiä:

• Ohjelmistosi ei kaatu 10 miljardin jäsenen kaaviossa (riippumatta siitä, kuinka monta yhteenliittämistä)
• Ohjelmistosi skaalautuu O:lla (solmujen määrä) ja O (reunojen lukumäärä^2)
• Ohjelmistosi voi tallentaa ja ladata uudelleen jokaisen perhekaavion jopa 10 miljardiin jäseneen asti

Suorittamalla simuloituja testejä löydät paljon outoja kulmakoteloita. Niiden korjaaminen vie paljon aikaa. Lisäksi menetät paljon optimointeja, ohjelmistosi toimii paljon hitaammin. Sinun on päätettävä, onko se sen arvoista ja kuuluuko tämä ohjelmistosi piiriin.

Kaikkien väitteiden poistamisen sijaan kannattaa silti tarkistaa asiat, kuten henkilö on oma vanhempi tai muut mahdottomat tilanteet ja esittää virhe. Ehkä antaa varoituksen, jos se on epätodennäköistä, jotta käyttäjä voi silti havaita yleiset syöttövirheet, mutta se toimii, jos kaikki on oikein.

Tallettaisin tiedot vektoriin, jossa on pysyvä kokonaisluku jokaiselle henkilölle ja tallentaisin vanhemmat ja lapset henkilöihin, joissa mainittu int on vektorin indeksi. Tämä olisi melko nopea siirtyä sukupolvien välillä (mutta hidasta esimerkiksi nimihauissa). Objektit olisivat järjestyksessä sen mukaan, milloin ne on luotu.

Kopioi isä (tai käytä symbolinkkiä/viittausta).

Jos esimerkiksi käytät hierarkkista tietokantaa:

$ #each person node has two nodes representing its parents.
$ mkdir Family
$ mkdir Family/Son
$ mkdir Family/Son/Daughter
$ mkdir Family/Son/Father
$ mkdir Family/Son/Daughter/Father
$ ln -s Family/Son/Daughter/Father Family/Son/Father
$ mkdir Family/Son/Daughter/Wife
$ tree Family
Family
└── Son
    ├── Daughter
    │   ├── Father
    │   └── Wife
    └── Father -> Family/Son/Daughter/Father

4 directories, 1 file