MySQL adatbázis tervezése
2010-01-27T22:53:40+01:00
2010-01-30T08:44:26+01:00
2022-06-30T19:11:38+02:00
  • Én amíg nem tudom az "igényt" magyarul elmondva, addig "információrendszerről" és "szervezésről" (hacsak eleve a munkát nem szervezte egy munkaszervező, de annak ehhez semmi köze ) nem igazán beszélnék.

    Még valamikor ilyet tanultam 1. lépésként:

    "a feladat megfogalmazása
    követelmények meghatározása, egyeztetés a leendő felhasználóval, a meglévő formanyomtatványok, listák megismerése, racionalizálása"

    Maximum ez után jöhet bármiféle információrendszer, vagy számítástechnikához kapcsolódó feladat.
    Mutasd a teljes hozzászólást!
  • Hát .... lehet, hogy ugyanarról beszélünk, csak másképp mondjuk ...... ahogy mi tanultuk, ez az "igényfelmérés" a információrendszer-szervezési folyamat első lépése. Ennek alapján történik meg a szervezés, ami megadja az adatokat (fejlesztési terv) az adatbázis tervezőnek és a programozónak is.
    Mutasd a teljes hozzászólást!
  • Sikerült kiválasztani egy jelentkezőt.
    Köszi mindenkinek a jelentkezést.
    Mutasd a teljes hozzászólást!
  • Az általad "igényfelmérés"-nek nevezett folyamatot az informatika berkeiben "információrendszer-szervezés"-nek szokás nevezni

    Amikor még én tanultam, az igényfelmérés a tervezés első lépése volt. Igényfelmérésnek hívták és az az volt, aminél leülsz a foszerral és megtudakolod, hogy mit is szeretne megvalósítani. Az információt csak utána "szervezed". Ott már Te(nem Ti!) leírod , hogy milyen feladatokat lát el a készülő program (feladatspecifikáció, használati esetek), milyen főbb, az alkalmazás-logika szempontjából fontos osztályokat kell megvalósítani. A következő lépés már az adatbázis logikai, majd abból a fizikai tervezése. Mivel csak az adatbázisig kell eljutni az ügyféllel, itt le lehet állni a tervezéssel. De nem gondolom, hogy a cégtől egy kész domain modelt kapna bárki is, így az igényfelméréstől kell idáig eljutni. Viszont, ha nem megy tovább a tervezés, akkor a programozó szinte az egészet kezdheti elölről, és nála fog kiderülni, hogy amúgy a két legfontosabb osztály (itt értsd tábla) hiányzik a programból. De addig a db tervezője a pénzzel már messze jár...
    Mutasd a teljes hozzászólást!


  • Ez engem is érdekelne majd .....
    Mutasd a teljes hozzászólást!
  • Az általad "igényfelmérés"-nek nevezett folyamatot az informatika berkeiben "információrendszer-szervezés"-nek szokás nevezni ..... és külön szakma. Az információrendszer-szervező adja meg a dokumentációt az adatbázis-menedzsernek, aki megtervezi azt .....

    ... nos ... ennek a szakmának része az is, amire te kívántad felhívni a figyelmet ... most nem írnám le részletesen az egész elvi folyamatot ... ;)

    Az már csak zárójelben mondom, hogy te - a saját érdekedben - nem fogod megúszni az együtt-dolgozást a tervezővel, mert ő a sajárt esze és logikája szerint fog tervezni, s ha a folyamatban nem veszel részt, akkor igen sokat szívhatsz az elkészülő - s szervező logikája mentén egyébként brilliánsan megtervezett - adatbázissal.
    Mutasd a teljes hozzászólást!
  • Megtennéd, hogy 5 hónap múlva újra benézel ide, és elmeséled, hogy áll a projekt? Köszi.
    Mutasd a teljes hozzászólást!
  • Folyamatirányítást nem kértek, adatbázist kell tervezned. Ha elvállalod, jó ha tudod, hogy mit vállalsz.
    És nagyon jól teszed, ha papírra vésed az igényeket és aláíratod, mielőtt nekiesel. Ráadásul én az igényfelmérést is órabérbe tenném. Az első megkezdett óra ott kezdődik, hogy a portán jelentkezem az épületbe való bejutás érdekében (tehát amikor gyalogolnod kell a 1,5 km-re lévő irodáig, mert a portás megtiltja hogy kocsival továbbhajts, az már számítson). Én már szívtam azzal, hogy a cég megvárakoztatott, mert fix árat mondtam. Szépen lassan vitatkozva ecsetelgették, hogy mit szeretnének, először, majd ha kész van megnézik és továbblépünk. Kis naiv voltam, soha többet Órabérben keressék meg a megfelelő szakit, kollégát is, aki megmondhatja a frankót. Órabérben vitatkozzanak előttem arról is, hogy hát hogy is kellene működjön a program. És különösen vésd fel a tervre azokat, amikre állítják, hogy soha nem fordulhat elő, miközben látszik, hogy igen nagy a valószínűsége hogy lehet olyan.
    Mutasd a teljes hozzászólást!
  • Ebben simán igazad lehet. Sajnos...
    Az más kérdés, hogy esetünkben a project látszólag bukásra van ítélve a hozzáértés hiánya és a hozzáállás miatt. De egyébként kevés az infóm ahhoz, hogy ítélkezzek.
    Mutasd a teljes hozzászólást!


  • Nem pedálozok hogy megkapjam, van miből élnem. De ami tény, az tény. Dolgoztam már vállalkozóknak, és nagyon ritka az, aki fel bírja fogni, hogy a folyamatirányítás nem egyenlő a papírgyártással, (lásd ISO és társai) hanem lehet értelmesen is használni.

    Mutasd a teljes hozzászólást!
  • Kell a munka, mi?
    (Ne haragudj, ezt nem hagyhattam ki...)
    Mutasd a teljes hozzászólást!
  • Szerintem igen ritka esemény, hogy valaki Üzleti folyamat alapú rendszert szeretne megrendelni.

    Meg tudom érteni, hogy körülnéztek a piacon, és a saját fejlesztés mellett döntöttek. A néhány évvel ezelőtti magyar piacon nem volt olyan vállalatirányítási rendszer, ami folyamat alapú lett volna, és megfelelt volna a kkv-k igényeinek.

    Aki ilyen döntést hoz, az igazán akar valamit! Le a kalappal.
    Mutasd a teljes hozzászólást!
  • Hali!

    Elküldtem az elérhetőségemet PM-ben.
    Mutasd a teljes hozzászólást!
  • Írtam pü-t.

    Mutasd a teljes hozzászólást!
  • Hja. Az csak a baj, hogy a (sztem borítékolható) kudarcért Te leszel a felelős, Téged fognak baszogatni.
    Mutasd a teljes hozzászólást!
  • Nem veszem személyeskedésnek amit írsz valószínűleg igazad van. A programot meg ha akarom ha nem, akkor is nekem kell csinálni (de inkább nem akarnám, de kell). Vidéken nem nagyon lehet most ugrálni munkahelyügyben, főleg mostanság. Azt csinálom amit mondanak és akkor kapok fizetést.
    Mutasd a teljes hozzászólást!
  • Itt nem a megrendelővel van gond, hanem veled. Már bocs a személyeskedésért. A programot Te akarod írni, a DB-t meg írja meg más. Szuperul meg is írja, Te ott se leszel, ahogy most olvasható. Aztán esetleg kereshetsz rá olyat, aki megírja a programot, mert a Te eszközeid esetleg alkalmatlanok lesznek rá. Nagyon jó példa az általam említett hiearchikus adatkezelés. Delphi 7.-ben most hirtelen azt sem tudnám hogy álljak neki.
    Egyáltalán miben akarod befejezni a programot? Az adatbázis elkészül, a tervezőt ki kell fizetni. Te meg nézel a lyukon, hogy mi hogy van. Pedig nem a db tervezőjének kell megírnia a statisztikai kimutatásokat. Az indexeket is többnyire elhanyagolhatja, mert majd neked kell összeállítani a lekérdezések alapján. Ráadásul idézlek:
    logika a kliens oldalon lenne

    Na mindegy, én csak neked akartam segíteni. A munkát még én is elvállalnám, ha lenne időm bejárkálni az ügyfélhez. Mert ennél egyszerübb feladat nincs.
    Mutasd a teljes hozzászólást!
  • Itt szerintem félreértés van, adott egy megrendelő aki akar valamit, és fizetne is érte. Ehhez keres embert.
    Határozott elképzelései vannak, még akkor is ha nem ért a témához. Ezeket az általatok leírtakat már sokan elmondták nekik, de nem érdekli őket.
    Itt most vagy azt mondod, hogy ekkora gányoláshoz én nem adom a nevem, vagy megcsinálod amit kér. Legfeljebb elkészülne egy olyan program amit soha senki nem fog használni (nem ez lenne az első a cég életében sajna).

    Félreértés ne legyen az adatbázis tervezővel nem én fogok kommunikálni hanem aki az üzleti folyamatokat menedszeli, mivel ő tudja jól a folyamatokat elmondani.
    Mutasd a teljes hozzászólást!
  • Olyanról még nem hallottál hogy szótár tábla? És olyanról hogy
    hierarchikus adatkezelés? Nemcsak hogy rengeteg táblát megspórolhatsz ezekkel, de sokkal testreszabhatóbb a program.
    Ezek használata pedig mind rajtad fog múlni és nem a db tervezőjén. Ráadásul igen specifikus a használatuk, mert ha jól tudom az utóbbi beépítve található az Oracleben. Tehát amit kézzel összetákolsz MySQL-ben, majd át kell gányolni Oracle alá.
    És ügye nem mondtál arról semmit, hogy mivel akarsz fejleszteni. Pedig ha például delphivel (pl:7-es) fejlesztesz, a kétkulcsos tábláknak szívből fogsz örülni.

    Ha olyan pontos leírást tudnék adni akkor nekifognék magam
    Ez pedig ügye vicc? Gondolod, hogy akár a legprofibb tervezőnek nem lesz szüksége a rendszer leírására? Ha pedig megvan a leírás, minden lépés elött meg kell kérdezzen róla, hogy "ez így jó lesz?".
    Mutasd a teljes hozzászólást!
  • Felmerült az a lehetőség is, hogy keresünk egy kész programot.
    De az a helyzet, hogy én egy alkalmazott vagyok aki azt csinálja amit a vezetőség mond neki, még akkor is ha én másképp csinálnám a dolgokat (különben nem adnak fizetést ). A döntéseket nem én hozom.
    Mutasd a teljes hozzászólást!
  • Az adatbázis struktúra kialakítás és "Az SQL szerverek közötti minél könnyebb hordozhatóság" szerintem nem igazán fér össze.
    Az adatelérési réteget kell arra felkészíteni, hogy több fajta SQL serverrel is képes legyen kommunikálni, pl. ADODB vagy hasonló, nem pedig az adatbázis struktúrát.

    Ha azt mondod, hogy user loginhoz kell adatbázis tábla, az valszeg majdnem minden sql-ben hasonló lesz, de 3-400 tábla esetén igen erősen figyelembe kell venni az adott sql szerver sajétosságait.

    Az előttem szólókkal pedig teljesen egyetértek, és szívleld meg a tanácsaikat.
    Mutasd a teljes hozzászólást!
  • A 3-400 tábla az az én tippem csak, annál biztosan nem lesz több.
    Abból indultam ki, hogy egy egyszerű számlázó porgram készletnyilvántartással kb 30-50 tábla lehet. Itt szerintem nagyon sok lenne a típustábla amit csak 5-10 rekordot tartalmaz.
    Az is lehet, hogy kevesebb táblával is meg lehet oldani, az már az adatbázis tervező feladata lenne, én csak támpontot próbáltam adni. Ha olyan pontos leírást tudnék adni akkor nekifognék magam
    Az SQL szerverek közötti minél könnyebb hordozhatóság fontos szempont, még ha 100 százalékban gondolom nem is valósítható meg.
    Mutasd a teljes hozzászólást!
  • csabi31-nek teljesen igaza van, vegyetek egy készet és szabjátok/szabassátok testre. A sok kidobott pénz és idő után úgyis ez jönne.
    Mutasd a teljes hozzászólást!
  • Ha jól sejtem, LC-nek van valami olyasmi rendszere, mint amit szeretnétek, reménykedj, hogy erre téved.
    (nekem nincs, én egyedit fejlesztek, szóval van róla sejtésem, miről beszéltem az előbb )
    Mutasd a teljes hozzászólást!
  • Tyűha. 3-400 tábla igen összetett szoftvert sejtet, ez esetben viszont totál zsákutca a mini programokra jellemző "logika a kliens oldalon" design. Nagy program esetén mindig lesz változtatás-igény és bug, ami esetben elengedhetetlen, hogy legyen egy fejlesztőgárda, aki mindenhez hozzá tud szólni, de akkor már miért ne ők terveznék az adatbázist. Nyilván Te nem rendelkezel ezzel, ezért is adtad fel ezt a hirdetést.
    Ezt a hozzászólást gondolatébresztőnek szántam csak, nem kritikának. 3-400 táblás szoftver egész egyszerűen ilyen módon halál lesz, valószínűleg sosem fog elkészülni, de persze ne legyen igazam.
    Mutasd a teljes hozzászólást!
  • Vegyetek inkább készet, az olcsóbb, gyorsabb, biztosabb. Mivel a kereskedelem nem egyedi valami. Egyedit fejleszteni drága, lassú, bizonytalan, nagy kockázat. Csak olyankor éri meg, ha nincs a piacon kész, ami (közel) megfelel az igényeknek.

    Amit ideírtál az önmagában is arra utal, hogy nem sok fogalmatok van a fejlesztésről. 3-400 tábla? 4 hónap? Ez a kettő nekem nem nagyon jön össze, a táblák száma ugyanis meglehetősen komplex rendszerre utal, az idő viszont meglehetősen egyszerűre.

    A "tárolt eljárás nem lesz" szintén arra utal, hogy jobb, ha bele sem kezdtek.

    Hidd el, rengeteget spóroltok, ha megszívlelitek ezt a tanácsot. (és csak az 5%-át kérem tanácsadási díjként )
    Mutasd a teljes hozzászólást!
  • Egy adott munkára keresek embert, nem állást ajánlok. Távolról is elvégezhető, ha az elején 3-4 napot személyesen találkozunk.
    A cégünk szeretne saját számára egy programot írni amivel a folyamatait menedzselni tudja (kereskedelem). A klienst oldalt én írom a szerver mysql. Az adatbázis struktúrát kellene megtervezni, megcsinálni, és a kliens számára a lekérdezéseket elkészíteni, insert update utasítások, stb. Tárolt eljárás nem lesz, a logika a kliens oldalon lenne. Lehetőleg olyan adatbázis struktúra kellene ami viszonylag könnyen átültethető lenne más szerverre (pl oracle) ha szükséges.
    Kb. 4 hónap lenne rá, 3-400 tábla, legnagyobb tábla is max 100 000 rekord.
    Szerintem kb. napi 4-6 óra munka, az elszámolás óradíjban történne, számlát kérünk. Írjátok meg azt is mennyi lenne az óradíj (x forint+áfa).
    Mutasd a teljes hozzászólást!
abcd