Pinus Nigra Creative Commons License 2019.07.10 0 0 387

"A térképen abból semmi nem látszik, hogy két egymást keresztező objektumnak van-e közös pontja."

Útvonaltervezési logikát NEM tárolunk geometriában. 
Azért vicces, hogy ezt olyannak kell leírni, aki a saját vállát simogatja, hogy ő mennyire pro, de még egyszer:
Az adattárolást nem keverjük az üzleti logikával, az üzleti logikát nem keverjük a felhasználói felülettel.

Nem azt kell tárolni az adatbázisban, hogy 
id|név|nettó|bruttó|áfa
1 |xyz|100   |127   |27

hanem azt, hogy 

id|név|nettó|áfa
1 |xyz|100  |27

és készíteni egy függvényt:

bruttó (termék_id, áfakulcs)

ami kikeresi a termékhez tartozó nettó árat, áfa kulcsot, és kiszámítja a bruttó árat. És nem azt adja eredményül, hogy <div style="színes csicsás megjelenés">127 forint</div>, hanem annyit, hogy 127, mert a megjelenésről már a felhasználói felület gondoskodik, a saját szabályai szerint. 

Az út geometriája adat.
Az útvonaltervezés az üzleti logika.
A térképen megjelenés (akár raszter, akár vektor) a felhasználói felület.

Nem szabad, illetve nem lehet összekeverni a rétegeket, mert körülményessé teszi a hibakeresést, és megakadályozza a fejlesztést. Ha a rétegek, megfelelően, külön vannak kezelve, akkor egyes rétegek cserélhetőek, vagy párhuzamosan működtethetőek:  pl. új útvonaltervező beállítható , hogy sem az adatstruktúrán, sem a megjelenítésen nem kell változtatni.

Az, hogy geometriában tároljunk útvonaltervezési adatot, annyira illogikus, hogy azért kértem tőled a teljesítménybéli növekedések értékeit, mert azt gondoltam, hogy bizonyára olyan mértékű, ami ellensúlyozza a nyilvánvaló hátrányokat. De te ilyet nem tudtál felhozni, érvelésed lényege annyi volt, hogy szerinted ez jó ötlet.

Előzmény: alnibell (382)