Hirdetés

Keresés

Új hozzászólás Aktív témák

  • Sk8erPeter

    nagyúr

    válasz -=Flatline=- #2128 üzenetére

    "Az totál jogos kérdés, hogy miért jobb nekem, ha két közepes méretű adatbázis lesz betöltve, nem pedig egy nagy, de vezéreljenek mondjuk magasztos átláthatósági szempontok :)"
    Rossz megközelítés. Neked nem kell olvasgatnod az adatbázist, ne azt akard átlátni, legfeljebb a struktúráját alakítsd ki értelemszerűen. Jó esetben nem közvetlenül az adatbázisban fogsz kotorászni, hanem készítesz egy megfelelő UI-t arra, hogy szűrni lehessen az adatbázisban tárolt adatokra. Az tök más kérdés, hogy kezelhető legyen, az adatok megfelelően legyenek normalizálva, legyenek szétbontva logikusan a táblák, majd a lekérdezéskor legyenek jól összekapcsolva. A 78 ezer mező meg aztán végképp nem érv, hogy szétbontsd, az a mennyiség jól indexelt táblák és normálisan megírt lekérdezések esetén tényleg semmi egy mai átlagos adatbázismotornak, másodpercnek pici törtrésze alatt lehet ennyi adat közt keresni.

    "78ezer rekordos már így is ami van és 15 mezőt tartalmaznak. Húzós dolgozni vele, ezt kell az upgradekor szétbontanom és, ha már itt tartunk, próbálnám egyszerűsíteni a júzer dolgát."
    Hogy a júzernek mennyire van egyszerűsítve a dolga, ahhoz aztán abszolúte SEMMI köze annak, hogy az adattáblákba mennyi rekord van feltöltve, és a háttérben lévő adatbázis+táblák milyen struktúrájúak. :N Attól még lehet nagyon felhasználóbarát egy felület, hogy a háttérben lévő adatbázisszerkezet egy fostalicska, és fordítva is igaz lehet, ha rosszul csinálják.
    A 15 mezőn mondjuk érdemes lehet elgondolkodni, kell-e, hogy mindegyik azonos táblában legyen, vagy érdemes inkább szétbontani, majd lekérdezéskor összekapcsolni (normalizálás).

    Egyébként ha ilyen bonyolultan fogalmazod meg a kérdést, akkor elmehet sokaknak a kedve, stackoverflow-n sem sokan tolongtak, pedig azért ott szoktak lenni válaszok, szerintem a "Complex autocomplete query" sem túl jó címválasztás, nem érzem igazán komplexnek a feladatodat (bár így fél 3-kor nem sokat fogtam fel belőle, mert annyira cifráztad, különösebben nem is gondolkoztam rajta), mégis elrettentő lehet a cím; valamint egy szemléltető ábra, a form megmutatása, valami tök egyértelmű rávezetés olykor többet mond minden szónál.

  • Jim-Y

    veterán

    válasz -=Flatline=- #2128 üzenetére

    Csak szerinted sok az a 78K, én melóban örülök ha ilyennel kell dolgoznom, mert azon értelmes időben lefutnak a query-k :D Nekem a 70millió soros táblával volt bajom :P

    Na, így már jobban értem a problémát. Nos, én először valamilyen formában eltárolnám még kliens oldalon, hogy melyik filmet szerkeszti, majd a leendő query-be ezt feltételnek írnám (nyílván ha úgy áll a kapcsoló). Tegyük fel BögyösMaca karakterére keresne a cikk közben, elkezdi gépelni, hogy 'Bögy' majd megáll
    -3 karakter megvolt, vársz 2 másodpercet, hogy folytatja-e a gépelést, ha nem, akkor mehet az ajax, mégpedig úgy, hogy az ajax data mezőjében elküldöd a Bögy stringet, és, hogy épp mi az aktív film, pl:

    $.ajax({
    ..
    data: {
    phrase: "Bögy",
    active: "Titanic",
    amikellmég: "azmegyide"
    }
    ..
    });

    Ezt szerveroldalon feldolgozod, és csinálsz belőle egy hozzá passzoló query-t
    SELECT * FROM Filmek WHERE title = 'Titanic' AND (szereplő LIKE ' %Bögy%' OR másikszereplo LIKE '%Bögy%' stb...);

    Visszakapsz x sort mondjuk, azt feldolgozod szerveroldalon encodolod json-be, és visszaküldöd a kliensnek.
    Kliensoldalon egyrész listázod autocomplettel a találatokat valamilyen emészthető formában, hogy az író ki tudja választani, hogy melyik érdekli, melyiket akarja beszúrni, majd megnyomja a gombot.

    Ekkor te visszakeresed az ajax eredménytömbjében ugyanazt az elemet, csinálsz belőle egy linket és beszúrod a kívánt helyre.

    Ne haragudj, hogy nem írok konkrét dolgokat, de még mindig nem látom, hogy hol akadtál el a dologban :(

Új hozzászólás Aktív témák

Hirdetés