>El nem tudom képzelni, hogy egy 1000mezős táblára értelmezhető és könnyen változtataható(!) lekérdezéseket lehetne csinálni.
Nagyon érdekes a téma... ;)
Tapasztalatból mondom, hogy vannak olyan feladatok/implementációk, ahol bizony nagyon sok oszlopra van szükség. Gondolj például arra amikor valaki egy hatalmas - számára így "beszédes" - kétdimenziós crosstab(=Excelben->pivot) táblában gondolkodik (amit, ha ma már esetleg támogat is az Oracle /ezt most nincs kedvem verifikálni/, nagyon sokáig, kétmenetes dinamikus sql generálásos módszerrel támogatott csak sql-szinten). Nyílván nem a relációs adatmodellezés 'csúcsa', de mivel természetes emberi korlátokat figyelembevevő megoldás, meglehet -> érdemes számolni vele...
Láttam olyat is, hogy az idődimenzió volt a vizszintes tengelyen az oszlopokban(!!!), és újabb oszlopok hozzáadásával nőtt az idővel a tábla... Sőt! Migráltam is ilyet Oracle alá (ami első ránézésre annyira azért nem volt trivi, 999 oszloposra szétdobott táblákat, adatszótár segítségével oszlop-sor transzformálni)
Nem tudom mennyire közismert a SAS (www.sas.com), ami egy másik 'hightech' dimenzió az Oracle-hez képest, mind termékpalettát, mind árakat tekintve (ami miatt is igen kevéssé elterjedt itthon), például adatbázis-megoldásában kvázi egyenrangúvá teszi az oszlopokat és a sorokat, mind elérés (programozható oszlopelérés, makróváltozóval), mind korlátok szempontjából.
El nem tudom képzelni, hogy egy 1000mezős táblára értelmezhető és könnyen változtataható(!) lekérdezéseket lehetne csinálni. Ráadásul nem is valószínű, hogy van értelme: az oszlopszám növekedésével az adatmodell átláthatósága jelentősen csökken. Halálosztó adatmodellje sokkal flexibilisebb és nem kell változtatni, ha új kérdést akarsz tenni az űrlapra - elég csak az új kérdést leírni a kérdések táblában. A relációs adatbázisokat pont ilyen adatmodellekhez találták ki, ezért nagyon nem fekszik nekik az 1000 oszlop. Eddig a legtöbb oszlop amit láttam egy táblában, az kevéssel 300 alatt volt, de már az is egy csomó adatot duplikált - ezáltal a szépséget a sebesség oltárán feláldozva. De ez egy szép nagy (terrás) adattárház közepében csücsült, ezért megbocsátható, hogy még aznap szerették volna megkapni a select eredményét... Ha egy tábla lehetőleg egy valós objektumot reprezentál, az oszlopok pedig ennek az jellemzőit, akkor elég valószínű, hogy egy 1000 jellemzős valami nem lesz oszthatatlan: lehet találni olyan alobjektumokat, amikből felépül, és ezeket kell leírni, meg hogy hogyan is építik fel az objektumot.
Az engem is rettenetesen érdekelne, hogy hogyan tudod a széles (1000 oszlopos) táblát gyorsan lekérdezni (1 körben), ha joinolós változatot (by halálosztó) csak 2 körben. Egyátalán hogyan történne ez a 2 körös verzió és hogyan folyik most az 1 körös?
Amúgy milyen nagyságrendekről beszélgetünk? Hányféle kérdőívtípus van? Hány sor van ebben az 1000oszlopos táblában (vagyis hány kitöltött kérdőívetek van)? Hány mező szokott lenni egy kérdőíven?
The absolute maximum number of columns in a table is 1000. However, when you create an object table or a relational table with columns of object, nested table, varray, or REF type, Oracle Database maps the columns of the user-defined types to relational columns, in effect creating hidden columns that count toward the 1000-column limit.
Szia, természetes, hogy a kulcs rész ismétlődik. De a válaszok jókora részét se érdemes külön mezőbe tenned. Mit érsz 1000 varchar(2) mezővel, amiben 'I', 'N', vagy üres. Konkatenáld össze a válaszokat, substr-rel pedig kiértékelheted. Édesviz
Ha kell irnod egy fuggvenyt, ami bemenetkent kapja az urlapmezo sorszamat, es a feletelt (legyen egyszeruseg kedveert egyenlosegi feltetel) akkor hogyan kodolod le?
"amikor a leválogatási szempontokat meghatározzuk, akkor annak itt egy olyan rekordcsoportra kell vonatkoznia, amely rekordcsoport jelentős része nem rendelkezik a leválogatási szemponthoz tartozó információval. Ezért csak két körben lehet meghatározni a leválogatandó rekordokat."
Ez alatt mit ertesz? Legyenek a mezok veznev, kernev, neme, a kerdoivek aiv, biv, civ.
Valaszok tabla KerdesID IvID Valasz ------------- -------- ---------- 1 1 Kovacs 2 1 Elek 3 1 Ferfi 1 2 Nagy 2 2 Lilla 3 2 No 1 3 Titok
Ha meg akarjuk tudni mely kerdoiveket toltottek ki ferfiak:
select k.* from kerdoivek k, valaszok v, kerdesek kr where v.kerdesID = kr.kerdesID and v.IvID = k.IvID and kr.Kerdes='neme' and v.Valasz='ferfi'
Ebben nem lesznek benne amikre nem toltottek ki nemet, de arrol nem is tudjuk. Ha az kell hogy ferfi vagy ures, akkor el kell olvasni a doksiban az outer join vagy az union cimszavakat.
Amikor kitöltött űrlapokat akarunk feldolgozni, akkor előfordul, hogy az űrlapnak ezernél több mezője van. Az igaz, hogy a keresett űrlapok leválogatásánál nem kell az összes mezőt megjeleníteni, de a megjelenítendő mezők összetétele esetenként változik.
A halaloszto által javasolt megoldásban azt látom problémásnak, hogy amikor a leválogatási szempontokat meghatározzuk, akkor annak itt egy olyan rekordcsoportra kell vonatkoznia, amely rekordcsoport jelentős része nem rendelkezik a leválogatási szemponthoz tartozó információval. Ezért csak két körben lehet meghatározni a leválogatandó rekordokat.
Az edesviz által javasolt megoldás jónak tűnik; különösen, ha rögzítjük, hogy mind a két tábla ugyanazt az ID-t használja.
Ha nem titok, valami iranyt adhatnal, hogy milyen problemahoz kellene ilyen tabla.
Az altalanos megoldas hogy csinalsz harom tablat: sorok, oszlopok, mezok. Ha varhatoan nem lesz minden sorban minden oszlop kitoltve, akkor mar csak diszkfoglalas miatt is erdemes.
Az ezer oszloppal mar azert is szivni fogsz, mert egy csomo eszkozben mindenfele buta korlatok vannak az sql max meretere.
Hogyan lehet beállítani azt, hogy egy adattáblában 1000-nél több mezőt is lehessen definiálni? (Az 1000 nem hatványa a kettőnek, ezért feltételezhető, hogy ez a határérték paraméterezhető.)
"megvárod a DB telepítéséért és -gondolom- üzemeltetéséért is felelős szakembert, aztán meg megosztod velünk, hogy mire jutottatok... ;)" ahogy ígértem, megosztom, hogy mi lehetett a hiba oka:
azt a feleltet kaptam, hogy a data dictionary-ból hiányoztak olyan dolgok
amik kellenek a normális működéshez, így a táblák/schemák törléséhez is.
A megoldás az lett, hogy legyalulták, és újrarakták az egészet.
Milyen bongeszovel probalod? Mert anno MSIE-nek volt (?) valami kis (?) bugja, hogy a :8080-at nem tudta portkent ertelmezni, hanem a host reszekent tekintett ra, szuksegszeruen hibas csatlakozasi kiserletet kivaltva ezzel. Sajnos a reszletekre mar nem emlekszem pontosan, annyi ideje nem hasznalom azt a bongeszdet.
Van egy szerverünk ( Oracle 8 ) , melyet virtualizálni fogunk. Maga az adatbázis része storage-n van. A storage-n lévő adatokat is át kell mozgatnunk máshová (uazon storagen belül). Ha az átmozgatott adatok megkapják uazt az elérési utat mint az eredeti lehet valamilyen probléma.
Van ötletetek vagy javaslatotok vagy bármi amire figyelni kell?
Politeness: Nem vagyok biztos benne, hogy nem volna haszontalan némi SQL és Oracle alapismeretet magaba szívnod, mielőtt gyakorlati alkalmazásokkal próbálkozol...
select to_char (<dátum_típusú_mező>,'DDD') from <tábla>;
vagy
select to_char (to_date ('2007-02-01', 'yyyy-mm-dd'),'DDD') from dual;
vazze. az yyyy.mm.dd nem azt jelenti hogy te ird oda az evet, hanem hogy majd o fogja. beture azt kell odaird hogy yyyy.
a format mask egy olyan leiras, ami alapjan tudja hogy hogyan alakitsa szovegge a datumot. az yyyy jelenti hogy legyszi adatbasiz ird ide az evet negy szamjeggyel, a mon jelenti hogy legyszi ird ide a honapot harom baetuvel roviditve, stb.
