több azonosító kinyerése egyetlen egy stringből

Adatbázis: SQL, XML DB

Sziasztok!

Szerintetek miként lehet a legelegánsabb módon megoldani az alábbi szituációt?

TableA.oszlopB-ben, egy stringbe van összefűzve a "bum=" utáni értéken a releváns adat, ami alapján össze tudnám joinolni a táblákat.A stringbe ágyazott adatok száma változó.

További nehezítés, hogy Access-ben kellene megvalósítani, így jópár finomságról le kell mondani.
TableA
+--oszlopA---+---oszlopB----------------------------------------------------+
| value1 | bim=2,bam=ahamm,bum=1;bim=56,bam=n,bum=2;
| value1 | bim=23,bam=invalid,bum=3;
| value2 | bim=12,bam=pron,bum=1;bim=44,bam=y,bum=2;bim=67,bam=y,bum=3;
| value3 | bim=67,bam=y,bum=2;
+---------------------------------------------------------------------------
TableB
+--oszlopC---+---oszlopB---+
| valueA | 2 |
| valueC | 1 |
| valueB | 3 |
| valueD | 2 |
+--------------------------+
TableEredmény
+--oszlopA--+--oszlopC---+---oszlopB---+
+-----------+------------+-------------+
A TableA normális esetben így nézne ki:
+--oszlopA---+---oszlopB--+
| value1 | 1 |
| value1 | 2 |
| value1 | 3 |
| value2 | 1 |
| value2 | 2 |
| value2 | 3 |
| value3 | 2 |
+-------------------------+

  • 6674 megtekintés

( horvmik | 2012. 09. 28., p – 07:49 )

Az instr függvényt próbáld használni a kivágási pozició meghatározására majd substr.

Ebbe a válaszba kis híján én is beleugrottam éjjel, aztán a növekvő csipa mellett azért kiszúrtam, hogy a keresett minta többször is szerepel a sztringben, más-más értékkel - szóval CSAK a gyári függvények nem sokat érnek.

Ilyenkor jön a kötelező MÁSIK javaslat, az UDF - benne ciklussal - ami táblát/tömböt ad vissza, amivel csak-csak lehetne kezdeni valamit, de ahogy a mi barátunk első 1-2 találata sejteti, Accessben ezt nem egyszerű accessni, többet viszont nem tudok az egészről.

yupp, pont ez a problémám...

Valami olyanra gondoltam, hogy mid-el vágom ki úgy, hogy instr-el léptetem a teljes stringen belül, míg nem null nem lesz.
De ezzel csak kapok egy tömböt/szebb halmazt.
Viszont, hogy ezt miként tolom be pl egy IN()-be azt még csak nem is sejtem...
--
"The only valid measurement of code quality: WTFs/min"

Ha az Access nem tud táblát visszaadó UDF-et (fogalmam sincs, de a google nem túl biztató), akkor az ideiglenes tábla feltöltése tárolt eljárásból (arra talán még képes...) az út.

- o -

Azért megjegyezném, hogy meglepő önszopatásnak tűnik az Access olyankor, amikor a közismert nyílt adatbáziskezelőkön kívül szabadon használható nagyobb, szoftvergyári motorok is elérhetőek.
De biztosan van oka.

( Jason v | 2012. 09. 28., p – 15:45 )

Bocs hogy ezt mondom, de ezt előbb normalizálni kéne, utána lehet vele dolgozni.
Mi hány ki ilyen adatokat? Kibaszni azonnal (kivéve persze, ha 400 milliós berendezés:).
Mekkora az adathalmaz? Ha soronként stringbasztatni kell, ez napokig fog futni.

Azért sejtem, hogy eredetileg nem annak szánták azokat a mezőket, amire most használatba lesznek véve.

Tipikus példa ilyesmire a "comment" mező, ami jellemzően arra születik, hogy ha végképp nincs hová besorolni valami érdemi információt, akkor se vesszen el, aztán ami lesz belőle:
- ahogy a júzerek kitapasztalják, hogy mi minden maradt ki a fejlesztésből, értelmesen, de persze szuboptimálisan használatba veszik, aztán lehet úgy elemezgetni, mint itt - ez a jobbik, de gyakoribb, hogy
- a nevesített mezők adatait is ide kezdik írni (amennyire az ui megengedi), mert könnyebb ideömleszteni kopipészttel.

kéne...de többe van mint 4 kiló, szóval nem lehet. Ez az ezt kell szeretni kategória.

Egyébként a történet úgy néz ki, hogy az "élő" adatbázisa oracle alapú úgy, hogy random nullázódnak/helyreállnak benne értékek. Ám ez a feature nincs hatással a működésre, tehát tekintsük csak tájékoztató jellegűnek.
Emiatt az adatokat exportálni kell manuálisan (xls), amit én visszatolok access-be, hogy ne VB-vel szopassam magam. És sajnos az xls már ilyen gyönyörű stringekkel rendelkezik.

Azért access-be mert elvileg az elérhető a leendő userek számára.

A most megvalósítandó funkcióhoz nem kell túl sok adat, 10 táblából kb 20 paramétert kell kivennem 1 "egységhez". Egyszerre kb 50 "egység" adatát kell lekérnem max 2x/nap. Csak hát lennének még további ötletek is...
--
"The only valid measurement of code quality: WTFs/min"

Ha már Oracle-ben van, akkor miért nem export előtt van gatyába rázva?

Ott azért kicsit több/kényelmesebb lehetőségek vannak szerintem mint az Access-ben.
Sőt sztem a cél struktúra is könnyeben felépíthető eleve onnan.

Természetesen ha van rá lehetőség + hozzáférés + hozzáértés ;)

ha már ott van oracle-ben, tudnom kellene használni de nem lehet, mert csak az export ad hiteles adatot (lásd fentebb). Ez adott. A miértet a vendor meg nem mondja meg. Ha inkompetencia, akkor azért, ha szándékos, akkor meg azért. Szvsz a kettő együtt.
Egyébiránt az a db is megérne egy misét...

Lehetőségem van az import előtt masszírozni az xls-en, de a VB nem a szívem csücske, próbálnám 1 rétegen megoldani.

--
"The only valid measurement of code quality: WTFs/min"

A minap vmelyik szomszéd topicban már kiderült, hogy ha valami nem normális egy db-ben, akkor nem feltétlenül kell erőltetni a db masszírozását, ha valamit el akarunk érni, mert a kedvenc szkriptnyelv mindig kéznél van.

Persze itt nem a VB-re gondolok, a PowerShell viszont teljesen kezes, és nem kopik el a billentyűzet, mire a szkript már csinálni is kezd valamit.

Természetesen a normalizálást mindig aláírom és aláhúzom, és dobálom a hajtűimet, amikor "20 rekorddal működik" alapon letojják, DE csekélységemnek is volt hasonló fícsört (naná, majd bug!) tartalmazó AS IS db-je.

A megoldás táblát visszaadó UDF lett (DB2).
A negatív hatása messze elmarad a LOB-ok indokolatlan használatából eredőtől.

( karsany | 2012. 09. 29., szo – 03:53 )

Ha jól értettem a kérdést, akkor itt az a cél, hogy a JOIN elkészüljön.

Magára a JOIN-ra szerintem megfelelő az alábbi:

SELECT *
  FROM TABLEA T1,
       TABLEB T2
 WHERE T1.OSZLOPB LIKE '%bum=' || T2.OSZLOPB || ';%';

Access-ben a ' helyett ", a % helyett * van, az összefűzés (||) helyett meg &. Ha jól emlékszem.