Fórumok
Nem tudom jó helyre nyitom-e a topicot, ez tűnt a legjobbnak.
Engem az érdekelne, hogy a 32bites és a 64bites rendszerek kompatibilisek-e egymással adatfájlok szintjén, avagy sem. Magyarul cserélgethetem-e szabadon a különböző verziókat egy gépen, úgy hogy közben a (bináris) adatfájlokat másolgatom? Az adott programtól függ, vagy globálisan kijelenthető hogy nem lehet gond, esetleg egyáltalán nem ajánlatos ilyet csinálni?
Hozzászólások
Az adott programtól függ
Ennyi. Ezt kár ennél tovább ragozni.
Azért általánosságban elmondható, hogy ha egy felhasználói program nem kompatibilis így, akkor az nagyon igénytelen.
--
joco voltam szevasz
Persze, de ez a felhasználó szemszögéből alapvetően csak indikatív dolog.
Hány emberről/cégről hallottál, aki aszerint választ az Oracle, a Sybase, meg mondjuk a DB2 közül, hogy melyiknek hordozhatóak a bináris adatbázisfájljai szóhossz-, endianness- és cpu-architektúra-függetlenül? Ez nem életszerű.
Pontosan.
Annál is inkább nem életszerű, mert ahol tényleg kiszolgál a szerver, ott a sebesség sosem kielégítő (ahol az, ott sem az), így aztán bűn volna azzal terhelni a feldolgozást, hogy a 32 bites megoldások overheadjét fojtony nyögje a 64 bites kód (elég bajuk van az adatfeldolgozóknak a multibájtos karakterkészletekkel). Az egyszeri migráció/konverzió tisztább, szárazabb érzés.
Elmeletben konnyu ezzel dobalozni, a valosagban amig nincs serializer api tamogatas pl akarcsak a pid tipushoz, addig eleg nehez ezt a fajta igenyesseget elvarni. Ki tudja milyen tipus az 32 vagy 64 biten vagy akarmilyen architekturan, plane elore latni hogy 2 ev mulva jonnek a 256 bites gepek ahol a pid a mostaninal 4x nagyobb lesz ;)
De lehet zoldseget mondok mert szerencsere ezer eve nem kellett raneznem ilyen temaban :)
--
cythoon
> a valosagban amig nincs serializer api tamogatas pl akarcsak a pid tipushoz
printf ...
> Ki tudja milyen tipus az 32 vagy 64 biten
es hogyan printf-elned? :)
--
NetBSD - Simplicity is prerequisite for reliability
> es hogyan printf-elned? :)
Addig fork-olnám a processzt, amíg a getpid elég kicsi nem lesz, és csak utána írnám ki, hogy takarékoskodjak a hellyel :-)
cseles:)
Szerintem elvárható, hogy ugyanaz legyen az adatfile. Ha pl kép az adat akkor sincs 32, meg 64 bites verzió. Ha valami cache szerű dologról volna szó akkor elképzelhető, hogy nem foglalkozik az átvihetőséggel a programozó.
+ Ha "váratlanul" leforgatnak egy 32-bites programot 64-re vagy fordítva, akkor előfordulhat, de linuxra írt programnál elég ciki lenne.
keres ra a postgresql 32 bit 64 bit szavakra ;)
___
info
Ez biztos nagyon szörnyű, de lehet, hogy csak egyszerű adatfile-okról kérdezett és nem adatbázisokról, amikről tényleg nem tudok sokat.
.......szerinted az adatbázis miben tárolja az adatokat?
pl valamilyen saját formátumban, ami word length és byte order független
"de lehet, hogy csak egyszerű adatfile-okról kérdezett és nem adatbázisokról"
.... éééés a megfejtés a gyengébbek kedvéért: az adatbázisok is adatfájlokban* tárolják az adatokat.
(*most az egyszerűség kedvéért tekintsünk el a raw-device jellegű adattárolástól.)
Ha a memória ide vonatkozó részét egy az egyben mented file-ba, az értelemszerűen nem hordozható különböző rendszerek (amik különböznek byte order és word length szinten) között, de mondjuk úgy, hogy ez a lehető legbutább megoldás amit el lehet képzelni (a leggyorsabb is, de ez már más tészta:)). Valamit valamiért
:)
Szó sem volt semmilyen byte orderről, meg hordozhatóságról.
A felettem szóló azt kifogásolta amikor a postgres-el példálóztak, hogy adatfájlokról kérdezett, és nem adatbázisokról.
Erre válaszoltam azt, hogy az adatbáziskezelők is általában adatfájlokban tartják az adataikat, tehát a példa amit felhoztak, megállja a helyét.
Egyébként meg pont, hogy az adatbázisoknál az elsődleges szempont a gyorsaság, tehát valószínű, hogy egy db engine fejlesztő nem a verziók közötti byte szintű kompatibilitást fogja szem előtt tartani, amikor az adatfájl kezelését írja.
Van köztes megoldás is, viszont ahhoz memória kell, bőven:)
Nem szükséges a kompatibilitáshoz lassúnak is lenni...
check ZFS ;-)
"check ZFS ;-)"
Elég gyorsan eljutottunk az adatfájloktól a fájlrendszerekig.... :)
végülis ez az alapja mindennek:D
van olyan vallás, amelynek tanításai szerint minden adatot tartalmazó valami tulajdonképpen adatbázis, a fájlok maguk, meg a fájlrendszerek is :D
Lásd még: "A Valóság Relációs Adatszerkezete" c. zsoltár. (Larry Könyve, IX. fejezet, 8. vers.)
:)
Kerdes, hogy az adott DB tervezesenel mi volt a lenyeg. Ha a sebesseg, valoszinuleg - ilyen szinten - nem hordozhato. Valoszinuleg ugyis van valami hordozhato formatuma, pl. verzio update-re, innentol kezdve felesleges is.
Mas kerdes, hogy DB eseten altalaban az IO alrendszer a szuk keresztmetszet, szoval a proci igazabol foglalkozhatna az on-the-fly konverzioval, van ra ideje. Ebben az esetben lehet hordozhato a formatum (meg ugye kodot karbantartani is konnyebb, ha minden architekturan ugyanugy nez ki a file).
--
Das "N" in RTL steht für Niveau... -Tuamo/Reel (?)
Nyosigomboc:
igen, az SQL dump, az ami "biztos", hogy mukodik
___
info
Ezzel a buta de gyors megoldással lett a DB2 a de facto leggyorsabb és mégsem legbutább adatbáziskezelő.
a funkcionalitást ne keverjük ide azért.
ezzel szemben még a memória dumpolása buta megoldás marad
Lapozásnak hívják, és nem véletlenül emlékeztet a neve az oprendszer által is használt buta módszerre.
"egyszerű adatfile-ok" vagyis nem kell annyit tudjanak, hogy egy egész adatbázis működjön rajtuk. Pl statikus adatok egy szótárprogramban, kép, hang, paletta, mindent kielégítő *.DAT kiterjesztés.
Csak egy egyszeru pelda:
long
Irj ki egy long valtozot 64 bit-en, es olvasd be 32 biten, de ha meg meg is akarod fuszerezni, akkor ird ki SPARC-on a 64 bit-est es olvasd be x86-on 32 bit-en. ;)
Jo szorakozast.
___
info
Architektúra különbséget nem hozott fel a kérdező.
Akkor kerlek ertelmezd a mondat elso felet. ;) A masodik fele az csak akkor, ha nagyon meresz.
___
info
Oooooké
amugy a megoldas:
#include < stdint.h >
es az abban definialt tipusok hasznalata.
___
info
+1, illetve az ntohs(), ntohl(), htons(), stb makro'k/fv-ek hasznalata.
sys/endian.h
NAME
bswap16, bswap32, bswap64, be16toh, be32toh, be64toh, htobe16, htobe32,
htobe64, htole16, htole32, htole64, le16toh, le32toh, le64toh, be16enc,
be16dec, be32enc, be32dec, be64enc, be64dec, le16enc, le16dec, le32enc,
le32dec, le64enc, le64dec -- byte order operations
___
info
afaik az nem hordozhato
de lenyegeben: fix endiannessel (celszeruen LE, az a trendy), fix bitmerettel kell tarolni, paddingre vigyazva pl.: __attribute__ ((__packed__))
erdemes tovabba bovithetore tervezni a formatumot, ha hozza kell adni/modositani kell
--
NetBSD - Simplicity is prerequisite for reliability
Amugy igen, sys/endian.h az BSD-s es nem POSIX.
es akkor meg figyelembe lehet venni a megfeleloen alignolt valtozokat is a structurakban, hogy nem a ketszereset foglaljak le, mint ami kellene, meg meg sok dolgot.
___
info
A leheto legrosszabb otlet adatot (pl structot) direktben mappelni, akkor is ha ovatos vagy alignmenttel es egyebekkel. Az stdlib tamogatas szart sem er, max egyes mezokre lehet kenyelmes.
Ugyanis az alignment platformfuggo (sparc pl azonnal szarraszall egy ilyenen), tehat neked kell _elore kitalalni_ hogy mit is akarsz tamogatni. Az ahoka altal emlitett bovithetoseg es hasonlok (pl verzio informacik egyeb meta adatok) miatt pedig vegkepp nem erdemes osszemosni az adattarolas formajat a memoriaban valo tarolas modjaval, mert csak onmagad szopatod.
--
cythoon
Ez a kérdés ebben a formában nem megválaszolható, lásd kommentek. Ki kell próbálnod az adott alkalmazásokat. A Firefox profil formátuma a tapasztalatom szerint könnyedén átvihető oprendszerek és 32 illetve 64 bites környezet között, de ez sajnos nem válasz a kérdésedre.
--
http://neurogadget.com/