Adatbázisunk felhasználása web-es célokra

A Symbol Ügyvitel adatbázisa egy sokat próbált, ingyenesen diszributálható, de fizetős változattal is rendelkező Firebird 2.1 adatbázis motor. Ez egy SQL adatbázis motor, bár sokan azt gondolják, hogy csak a Microsoft-nak van SQL-je, pedig az alábbiak is SQL motorok: Firebird, PostgreSQL, Oracle, MySQL.

Felhasználható-e a Firebird web célokra?

Mivel a Firebird szervernek létezik Linux-os változata (ez is kompatibilis a termékünkkel), telepíthető olyan számítógépre, ahol egy web kiszolgáló (Apache 2.2) is telepítésre került. A két komponens PHP-n keresztük jól megérti egymást. A web-es adatokat lehet Firebird adatbázisban tárolni és onnan kiszolgálni, de nem célszerű.

Alkalmas-e a Symbol Ügyvitel adatbázisa web célokra?

Amennyiben WEB célok alatt olyan működési módot értünk, ami néhány felhasználó számára az összes adat irányába elérhetőséget biztosít, akkor a válasz IGEN. Példa lehet erre egy Ticketing rendszer, ahol cégének ügyfelei belépnek a web-es felületre, ahol azonosítják magukat, majd megnézhetik, hol tart a rendelésük vagy a kért javításuk. Ennek kiszolgálására rendszerünk alkalmas.

Természetesen UTF8/Unicode üzemmódban tároljuk a szöveges adatokat,
így web-es környezetben sem merülhetnek fel ékezet problémák.

Alkalmas-e a Symbol Ügyvitel adatbázis portál célokra?

Ha portál célokra használnák a Symbol Ügyvitel terméktörzsét, NEM javasoljuk a használatot. Egy portál egyetlen oldalának felépítése során sok (>10) lekérdezés fut le. Köztük termékképek, termékcsoportok, készletinformációk, stb. Ezek kiszolgálására nem elég a Firebird adatbázis kezelő. Nem erre találták ki. Pláne, ha 10-20 konkurens felhasználót feltételezünk az oldalon, akik eszeveszetten kattintgatnak egy termék után kutatva.

Az adatbázis állandó?

Külön ki kell térni arra, hogy a Symbol Ügyvitel adatbázisa NEM állandó. Fenntartjuk magunknak a jogot, hogy adatbázisunk formátumát átalakítsuk. Általában bővíteni szoktuk a tárolandó adatok körét, ritkán használunk új mezőként valami olyat, amit kötelező kitölteni (NOT NULL), illetve kivételes esetben szüntetünk csak meg mezőket. A fentiek figyelembe vételével kicsi az esély, hogy egy jól megírt lekérdezés egy új verzióban ne fusson le, de elképzelhető.

Az adatbázis formátumáért külső felhasználási célból felelősséget nem tudunk vállalni,
még akkor sem ha adatbázisunk nyitott, a felhasználók adatait nem rejtjük el.

Akkor mi a megoldás?

Sok helyen (>50) jó megoldást jelent egy saját webáruház működtetése saját adatbázis motorral és ehhez egy illesztőfelület megvalósítása. Mikből lehet választani?

  • osCommerce
  • Joomla + VirtuaMart webáruház motor
  • Saját fejlesztés (PHP, Java, stb.)

Az illesztőfelületre nemsokára elkészül az általános megvalósításunk, aminek segítségével minden webfejlesztő saját webes megoldását (vagy valamilyen ingyenes megoldást) hozzáilleszthet a Symbol Ügyvitelhez. Ehhez cégünk közreműködésére nincs szükség. Szabadon letölthető WebSyX beépülőnk (nemsokára elérhető) szabadon tesztelhető, az általa küldött XML fájlok nyílt formában elérhetőek.

További információk: syx.symboltech.hu

QuickSort – ismét felfedeztük

Elméleti szinten oktatják a rendező algoritmusokat. Sok geek (megszállott) ennek jelentősséget is tulajdonít, pedig már nem számít. Gondoltuk a múlt hétig.

Elmúltak azok az idők, amikor 64kB RAM állt rendelkezésre és nagyon hatékony, gyakorlatilag kihegyezett algoritmust kellett írni mondjuk 200 dolgozó bérszámfejtési adatainak kezelésére. És nem mindenki tudta ezt megcsinálni.
Jelenleg az igazán sok adatot adatbázisokban kezeljük, nem számít a memória, a szerverben legyen sok.

A fejlesztők pedig 4-6 éve (Java-sok régebben) már túlléptek azon, hogy a numerikus analízisben megismert elveket kelljen ismerniük, hogy használható programot készítsenek. Mert beköszöntött a keretrendszerek kora. Ebben minden általánosan használt funkció már megírásra került, sőt eszközök is vannak arra, hogy a hiányzó részeket se tudjuk rosszul megírni (Generics, Interface, etc.)

Jó lenne ha emlékeznék, de nem fog menni. Valamikor a keretrendszer által támogatott rendező algoritmusok (Generic List Sort()) helyett sajátot készítettünk. (Ennek oka, hogy a BindingList-ben nincs sort, de ez mellékes). A saját pedig – minden bizonnyal – “pár napig jó lesz kipróbálni” szemlélet alapján egy gyors buborék rendezés lett. 4 sor, lehetetlen tévedni. Működött is. Majd a pár napból egy év lett.

Nem is lett volna baj, minden szépen működött, az SQL szerver rendesen kezelte a 80.000 terméket ügyfelünknél. Egészen addig, míg a 80.000 termék több, mint 5000 (!!!) gyártó alá került besorolásra. Ekkor a termékkiválasztó ablak megnyitása 30-50mp-et vett igénybe. A konzulens kollégák jelezték, hogy ez nem fatális hiba, emiatt nem kell azonnali verziót közzétenni, de minket mégis izgatott a dolog…

Quick Sort

És kb. egy órába telt, mire kiderült, hogy nem az adatbázis műveletek lassúak, nem is az 5000 gyártó combobox-ba feltöltése (valóságban más felületi elem, de példaképpen legyen combobox), hanem valahol belül egy adatátadás. És ekkor jött a homlokhoz csapás. A bubble-sort 5000 elem esetén statisztikailag 5000 x 2500 = 12.5M összehasonlítást végez és ennyi cserét is, ha kell. Ennek pedig ideje van. Egész számok helyett objektumok esetén még inkább.

A dolog sikerrel zárult, mert 3 órányi munka után a keretrendszerünk egy operáción esett át és a gyomor (körülbelül ez felel meg a rendező algoritmusoknak) újra egészségesen viselkedik. Persze újra felidézve tanulmányainkat rájöttünk, hogy a már rendezett adatokat a QSort nem is rendezi be újra, azaz még hatékonyabb lesz a működés.

Kis adatmennyiségek esetén nincs szerepe a fentieknek, de ott sem árt egy kis performancia-tuning.