Új hozzászólás Aktív témák
-
martonx
veterán
válasz Speeedfire #1137 üzenetére
Pont a múltkor kezdtem el noSQL-ezni, pont a mongoDB-vel. Én is még csak kostólgatom. Viszont ahhoz, hogy dönteni tudjak közülük (mármint RDBMS - noSQL közül, és ha noSQL, akkor melyik), bele kellett mélyednem az előny-hátrányaikba.
Még annyit tennék hozzá a fentebbi irományomhoz, hogy amit írtam, az a dokumentum alapú NoSQL-ekre vonatkozik. A kulcs-érték, gráf stb... típusú NoSQL-eknek értelemszerűen teljesen más előnyei lehetnek. RDBMS kiváltásához nyilván a dokumentum alapú NoSQL-eket szokták használni.Én kérek elnézést!
-
martonx
veterán
válasz WolfLenny #1146 üzenetére
MySQL 5.1-től fölfelé 64Tb-os 1-1 adatbázis méretkorlátja. Szerintem ennek a közelében sem lesztek.
Vasat nehéz javasolni, pláne, hogy eddig csak a havi bejövő adatmennyiségről volt szó. Tudni kellene, hogy a bejövő adatok írása mennyire oszlik szét időben, a lekérdezések mennyire történnek időben szétszórtan, illetve hány konkurens felhasználóra számítotok.
Általános tapasztalat, hogy legtöbbször a lemezműveletek viszik el a sok időt, még akkor is ha az adott DB szervernek sok memória áll a rendelkezésére. Manapság a sokmagos processzorok korában a processzor egyre kevésbé a szűk keresztmetszet.Én kérek elnézést!
-
martonx
veterán
válasz WolfLenny #1148 üzenetére
ez esetben abszolút nem kell erős hardver a mysql alá. Egy mai bármilyen alap szerver megteszi (kettő mag, pár guriga memória, egy kis raid tömb mondjuk 3 vinyóból, ha fontos a redundancia). Azért ha nem egy 10 éves egy magos xeon-on futtatnátok, az nem lenne hátrány.
Én kérek elnézést!
-
martonx
veterán
válasz Speeedfire #1150 üzenetére
Szvsz nem ajánlott keverni, legalábbis vagy RDBMS-t, vagy dokumentum alapú NoSQL-t érdemes használni. És e mellé persze könnyen lehet gráf tárolót, vagy kulcs-érték tárolót használni (lásd pl. Facebook, ami MySQL alapú, de a kapcsolatokat gráf tároló NoSQL-ben tartja).
Én kérek elnézést!
-
martonx
veterán
válasz kisbandima #1163 üzenetére
Ha már Silverlight, akkor gondolnám, hogy WCF RIA Services-el adod az adatokat, ez esetben LINQ-val simán meg lehet oldani az egészet.
Ha meg nem több millió adatsorról van szó, C#-al, XAML-lel elég szépen lehet memóriában szűrni az adathalmazt.Én kérek elnézést!
-
martonx
veterán
válasz Sk8erPeter #1179 üzenetére
Én inkább úgy mondanám, hogy mióta az Oracle kezében van, nem olyan a fejlődési üteme, mint régen. Az Oracle bolond lenne saját magának konkurenciát állítani.
Én kérek elnézést!
-
martonx
veterán
válasz Sk8erPeter #1182 üzenetére
Nincs itt nagyon mit megbeszélni. Az 5.1-es MySQL verzióban volt a legtöbb innováció. Ez pedig 2008 November 27-én jelent meg. Ez lassan 4 év távlatot jelent. lakisoft által jelzett újdonságok is ekkor kerültek bele. Azóta csak csiszolgatják.
Az Oracle pedig 2010 január 27-én vette meg a Sun-t, ami birtokolta a MySQL-t.
De ez részemről nagyon off topik, és nem vagyok egy nagy MySQL szakértő.Én kérek elnézést!
-
martonx
veterán
-
martonx
veterán
válasz WolfLenny #1199 üzenetére
Egyrészt a PHP mint interpreter nyelv az ilyen műveletekre alapvetően kb. 100X lassabb (lehet, hogy cak 10-szer, erről ne nyissunk vitát), mint egy compiled (pl. java, .net) nyelv.
Másrészt ha ezen a szerencsétlen P4-esen még emellett egy MySQL-t is futtatsz, és mindehhez egy ősrégi lassú vinyú kerreg alatta, akkor nem csoda ez a futásidő.Én kérek elnézést!
-
martonx
veterán
válasz SektorFlop #1224 üzenetére
join-os update-nek annyira más minden SQL nyelvjárásban a szintaktikája, hogy ajánlom a guglit. MSSQL-ben kapásból megmondtam volna.
Mondjuk ilyen triviális kérdésnél egyébként is elsőre guglizni illene...Én kérek elnézést!
-
martonx
veterán
válasz wolandino #1244 üzenetére
Te kevered a szerzont a fazonnal. MS SQL-ről beszélsz, mikor a connection stringet MS Access-re mutat.
Ráadásul mindezt Linuxon???
Nem fog menni. Megoldási lehetőségek:
1. Miért ragaszkodsz a Linux-hoz, ha már MS alapú az adatbázisod? Futtasd windows-on a PHP-t.
2. Elfelejted az mdb-det, és használsz helyette valami más SQL-t, mondjuk sqlite, mysql, postgresql. Ezek mind futnak linux-on is.Én kérek elnézést!
-
martonx
veterán
válasz wolandino #1246 üzenetére
Nem ismerem a lehetőségeidet, csak jeleztem, hogy amit szeretnél nem fog menni. Mindegy, hogy neten mit találtál, amíg az MS nem írja meg az Access ODBC-t linux alá, addig nem fog működni amit szeretnél. Márpedig az MS soha nem fogja az Access-t linux alá megírni.
És az MS Access akkor sem egyenlő MS SQL-el, ez olyan mintha egy Skoda Fabia-ra meg egy Porsche-ra mondanád, hogy de mindkettőt a VW cég gyártja.Én kérek elnézést!
-
martonx
veterán
válasz wolandino #1249 üzenetére
úristen, a linux coderek mindig meg tudnak lepni. Valaki képes volt ms access odbc drivert barkácsolni???
Mondjuk a cégünknél láttam olyan linux guru-t, aki magától írt drivert a megvásárolt faxcenterhez. Igaz az óradíja alapján annyit fizettünk érte, mintha vettünk volna egy elve rendes linux driverrel szállított faxcentertÉn kérek elnézést!
-
martonx
veterán
válasz wolandino #1257 üzenetére
"párhuzamosan kellene futnia az én alkalmazásomnak" - ezek szerint a linux-on futó PHP-s részt te csináltad. mdb mellé, linux-os PHP, meg valaki által házilag gányolt spanyol/olasz/portugál mdb odbc driver. Gratulálok
A kókányolás mintapéldája. Ha van rá lehetőség tényleg dobjátok ki az egész hóbelevancot, és csináljátok meg rendesen, konzisztensen.Én kérek elnézést!
-
martonx
veterán
válasz wolandino #1259 üzenetére
Én folyamatosan hasonló cipőben járok, nem győzzük kidobálni a régi szarokat. Mostanában ha minden igaz végre a PHP-s szutykok lesznek soron. Az access-es fosok kidobálása meg már több, mint egy éve tart.
Én csak azon mosolyogtam nagyon jót, hogy amikor az ember fejleszt, óhatatlanul is felteszi a kérdést, hogy mire akarom ezt a rendszert használni, milyen más rendszerekhez kell (majd) kapcsolódnia, milyen platformon, milyen nyelven érdemes nekiállni a fejlesztésnek, milyen régi szart tudok esetleg kiváltani vele stb...
Ha egyszer windows vonal, akkor legyen windows vonal. Ha linux, akkor legyen linux. Nincsen annál nagyobb szopás, mint amikor az ember linux-os PHP-ról próbál meg MS SQL-el kommunikálni (lehet persze, ahogy az mdb-vel is).
Én napi szinten párhuzamosan programozok PHP-ben, .Net-ben, és Vbscriptben (beleértve mindenféle makrót is). Ezek mellett linuxon van PostgreSQL-ünk, windowsokon van MS SQL-ünk, és Oracle-ünk. Szóval tudom, hogy milyen az amikor régi megörökölt szarokat kell párosítani. Manapság már meg se próbálom (ha nem muszáj), eleve úgy futok neki bárminek, hogy mit lehet egy közös modern techonlógiával kiváltani, ha már egyszer hozzá kell nyúlni. Vagy minden közé webservice-eket írok, kommunikáljanak azok egymással a megfelelő platformokon (lásd SOA).
És nem ezzel van bajom, hanem ismétlem azon mosolyogtam, hogy hogy lehet ennyire öncélúan, önszopató módon új rendszert fejlesztened, ahelyett hogy kiváltottál volna vele egy régi rendszert.Én kérek elnézést!
-
martonx
veterán
válasz Yushchenko #1271 üzenetére
Ha a saját mezőid, akkor talán nem char-t, hanem varchar-t kellene használni.
Másrészt meglepő módon Trim-el tudod a szóközöket csonkolni.Én kérek elnézést!
-
martonx
veterán
válasz sanzi89 #1278 üzenetére
INSERT INTO log (DateTime, TypeID) VALUES ({ ts '1990-12-31 00:00:00' } , 1)
1. próbáld ki kapcsos zárójellel a log-ot [log]-ként, lehet hogy az access a log-ot valami parancsszóként értelmezné tábla név helyett
2. { ts '1990-12-31 00:00:00' } - ez mi??? Valami ilyesmit próbálnék meg helyette: #2009-04-21 14:25:53# esetleg #'2009-04-21 14:25:53'#
3. Access-be belépve kapod ezt, vagy delphi-ből futtatva? Mert ha delphi-ből, akkor én megpróbálnám a helyedben access query-ből közvetlenül.Remélem segítettem, nagyon igyekszek távol tartani magam az access-től.
[ Szerkesztve ]
Én kérek elnézést!
-
martonx
veterán
válasz Sk8erPeter #1297 üzenetére
és ez még csak a PHP. Van még néhány nyelv, ahol nem is prepared statement-nek hívják
A lényeg azonban ugyanaz, kerülendő a konkatenálás.Én kérek elnézést!
-
martonx
veterán
válasz rum-cajsz #1323 üzenetére
mondjuk elnézve a problémákat (amellett, hogy access ellenes vagyok), pont nem az access maga a probléma, hanem egyrészt szarul lett felépítve a használt adatbázis, másrészt a program is szarul lett megírva ami ilyen duplikációkat hoz létre bele.
Ezek a hibák, ha béna a programozó, pont ugyanígy megmaradnak, bármilyen db motort is használjon az ember.Én kérek elnézést!
-
martonx
veterán
válasz Sk8erPeter #1362 üzenetére
Tudok több olyan nagy pénzintézetet mondani Magyarországon, ahol jelentős programok MS Access-ben vannak megvalósítva.
Én kérek elnézést!
-
martonx
veterán
Egy eset van, amikor az Access tényleg hasznos. Mindenhonnan magába tud fogadni adatokat, és ezekkel SQL szinten tudsz dolgozni.
Van pl. néhány klasszikus SQL szerveren futó táblád, meg van néhány rendszeresen frissülő TXT file-od, meg pár excel táblázatod. Ezeket SQL szerűen együtt kezelni, joinolni stb. MS Access-ben pár kattintás.
Nagyvállalati környezetben számtalan ilyen eset előfordul.
Persze meg lehet ezer más módon is oldani a fentebb vázolt problémát, de az MS Access-es megoldás a létező leggyorsabb, legegyszerűbb.Én kérek elnézést!
-
martonx
veterán
válasz PazsitZ #1366 üzenetére
Az SQL tudás mindennél többet ér (bár kitudja pár év múlva a NoSQL-ek felfutásával mire lesz jó a mostani SQL tudásunk ), az MS Access-ennek csak egy speciális vetülete. Az Access SQL meg különösen kilóg az SQL-ek sorából.
A fentebb hozott Access-es példámhoz egyébként SQL tudás kell. A kattitngatást nem arra értettem, hogy az Access designerével join-olod a táblákat, hanem az adatforrások Access-be behúzására. Személy szerint Access-ben is mindig kézzel írom az SQL kódot, a kód designert kb. soha nem használtam még benne.
És nehogy Access pártinak gondoljatok, csak próbáltam rávilágítani, hogy a világ nem szimplán fekete és fehér.Én kérek elnézést!
-
martonx
veterán
válasz Sk8erPeter #1373 üzenetére
Én 3 cégre látok rá, ezekből kettő az igazán nagyok között játszik (vagy legnagyobb? hm...) A harmadik is komoly tényező. Őszintén meglepődnék ha a többiek nagy részénél nem fordulna elő MS Access.
Én kérek elnézést!
-
martonx
veterán
válasz Apollo17hu #1375 üzenetére
ez most komoly kérdés volt?
Például a Dreamcoder for MySQL-hez na vajon mi kell? Segítek kell egy Dreamcoder, meg egy MySQL.
Töltsd le őket, és hajráÉn kérek elnézést!
-
martonx
veterán
válasz Apollo17hu #1377 üzenetére
Segítek. Next - next - finish. Közben mindent default-on hagysz. Nem bonyolult ez.
Én kérek elnézést!
-
-
martonx
veterán
válasz lakisoft #1385 üzenetére
Úgy mondanám, hogy Expressnél biztosan kell instance a szerver névhez.
Enterprise verziónál, ha ugyanazon db szerveren nem fut több különböző instance, akkor elvileg nincs is külön instance jelölés. Kivéve, ha a DB admin direkt úgy állította be, hogy akkor is legyen.
De nem vagyok DB admin, így nem vagyok 100%-kig biztos ez utóbbiban.Én kérek elnézést!
-
martonx
veterán
Szerintem erre nincsen igazán jó szakirodalom. Esetfüggő, hogy mikor mennyire érdemes normálformára hozni, milyen táblastruktúrát érdemes létrehozni, mennyire kell teletömni indexekkel egy-egy táblát stb...
Egy-két SQL optimalizálás problematika elég szokott lenni, hogy felnyissa az ember szemét a DB tervezés alapjaira.
Nagyon általánosságban beszélve: 1. - 2. normálforma elég szokott lenni. Láttam olyan DB-t, ahol még az Igen/Nem is normalizálva volt külön paraméter táblába. Nos, ez már a ló túlsó oldalára átesés.
Ugyanez a helyzet az indexelésekkel. Egy bizonyos szintig nagyon jó, hogy van mindenféle joinokban használt index-ed. Aztán mikor már mindenen index figyel és szegény db motor egy-egy insertnél nem győzi az indextáblákat frissíteni, akkor ez már kontraproduktív.
Nagyon nincs, és nem is lehet általános érvényű tanácsot adni SQL adatbázis tervezéshez.Én kérek elnézést!
-
martonx
veterán
válasz zolynet #1395 üzenetére
Egyébként bármilyen csúnya is SQL-ben ilyet használni, de egy While ciklus szerintem erre pont megfelel.
Második sortól kezdve végiglépdelsz rajta, mindig kiveszed az eggyel előző számot, és azt hozzáadod egy 0-ról induló változóhoz.
És továbbra sincs ebben semmi rekurzió.Én kérek elnézést!
-
martonx
veterán
Ez is hasznos, és naprakész kis olvasmány TSQL vonalon.
Én kérek elnézést!
-
martonx
veterán
-
martonx
veterán
Hány egyidejű felhasználója lesz? A közepes, vagy annál nagyobb teljesítmény nagyon szubjektív. Egy 16 processzoros (processzoronként 6 mag) szerver a maga több TByte memóriájával vajon közepes, vagy komoly gépnek számít? És amikor két szekrénnyi storage van mögötte? És ha 10 ilyen kiépített gép van fürtözve?
Ez a téma iszonyú relatív. Véleményem szerint egy SQL szervernek a legtöbbet a storage számítja. Egy több tucat vinyós (SSD-ről nem is beszélve) storage már elég szép teljesítményre képes. Emellett fontos még a sok memória, mert minél több táblát tud memóriába tartani az SQL annál kevesebbszer kell a vinyókhoz nyúlnia.
Összességében már egy mezei 1 processzoros (ami azért legyen egy modern minimum 4-6 magos processzor) szerver, a bele préselhető maximális vinyószámmal (hasraütés szerűen 8-10, SSD sokszoros gyorsulást jelent a hagyományos vinyókhoz képest), és az alaplapba tehető maximális memória mennyiséggel (szintén hasraütés szerűen 32GB) simán kiszolgálhat egy 1-200 fős céget, feltéve ha az ügyviteli rendszer jól ki van optimalizálva, plusz van kismillió ismeretlen tényező, ami ezt befolyásolhatja.
A sávszélesség is szubjektív, hogy kinek mi a megfelelő. Nekünk pl. 40 mbites dedikált vonalaink vannak a vidéki városokhoz, ezeken keresztül zökkenőmentes az adatok (nem csak adatbázis adatok, hanem komplett internet forgalom) áramlása.
Mivel semmi konkrét infót nem adtál, ezért csak nagyon nagy általánosságokat tudtam leírni.Én kérek elnézést!
-
martonx
veterán
Én a helyedben két dolgon gondolkoznék el nagyon erősen 300 fő kiszolgálása, kb. 100 egyidejű felhasználó esetén.
1. Venni egy szervert, amiben két processzoros alaplap van, de első körben csak 1 processzort használni benne. Ugyanígy a maximális vinyó számot se használnám ki, hanem mondjuk néhány (minimum 3 ugye) vinyóval egy RAID 5 vagy 10-es tömböt használnék (nem vagyok egy HW-s raid szakértő, hogy melyik a jobb, melyikhez minimum hány vinyó kell, szóval lehet most hülyeséget mondtam). Ekkor a RAID miatt megvan benne a hibatűrés, de a kevés vinyószám miatt az IO elérés lassú lesz. És mondjuk kezdetnek 8-16GB memóriát tennék bele. Ezzel neki lehetne vágni a műveletnek, fokozatosan átterhelni rá a mostani DB-ket, és monitorozni, hogy ez így kb. mit bír, a felhasználók mennyire panaszkodnak? Ha panaszkodnak, akkor lehet látni az adatokból, hogy IO, vagy CPU vonalon kell erősíteni (netán mindkettő). Erős IO használatnál kell a ramot is bővíteni, mert ugye a sok ram csökkenti az IO használatot. És ne felejtsük el, hogy kell egy kis teljesítményű szerver, ami backup-olja az adataidat, ettől helyileg teljesen elkülönítve.
2. Elfelejted az egész hardveres marháskodást és felhőbe viszed az egész cuccot. Ott aztán mindent úgy skálázol, ahogy jónak látod, meg ahogy a pénztárcád engedi. Az AWS-t, vagy az Azure-t javaslom, nekem az Azure-al vannak pozitív tapasztalataim. Mostanában jelent meg a T Systems, meg az Invitel is a saját felhő szolgáltatásaikkal, azokat nem ismerem. A felhő szvsz nem olcsó, de megspórolod a hardver árát, plusz a villanyszámlát havonta, a meghibásodásokat, hardveres kollega fizetését, db admin kollegát (na jó ezt nem teljesen) stb...
Én kérek elnézést!
-
martonx
veterán
1. mint mondtam az SQL szerverek általános szűk keresztmetszete az IO teljesítmény. Ezen vagy a meghajtók számának növelésével, vagy a meghajtók gyorsaságával (SSD-re cseréjével) lehet segíteni. Ha nem nagyok a DB-k, vagy a pénz nem számít, akkor mindenképpen az SSD-s megoldást javaslom. Ha éjszaka nem dolgoznak a DB szerveren, akkor mehet ezen a mentés, és elég azokat akár egy NAS-on tárolni. Ha éjjel-nappal pörög a DB szerver, akkor jobb, ha egy másik gép végzi a mentést.
2. a programozóid véleménye alapvetően butaság. Valóban nem 100%-os az átfedés az Azure és az SQL Server 2012 között, de ez csak ott jelentkezik, hogy nem tudod egy az egyben áttenni a DB-ket Azure-ra. Mostanra ez már elég szépen dokumentálva van, és ha valaki rászánja azt az 1-2 órát az életéből, és végre ott van a DB Azure-on, akkor már csak egy connection stringet kell kicserélni a programban, és az észre se veszi, hogy DB-t váltottak alatta.
Én kérek elnézést!
-
martonx
veterán
Elmondom én, hogy mik hiányoznak az Azure-ból TSQL szinten:
Elosztott tranzakciók
Elosztott lekérdezések
FILESTREAM Data
Beépített Full-Text Search
CLR
Service Broker
Fizikai szerver és katalógus
Adatbázis Mirroring
Extended Stored Procedures
Tábla particionálásEzek egy része már mostanra is deprecated technológia, azaz nem kellene használni. Másik része pedig a felhőből fakadóan felesleges pl. Adatbázis Mirroring. És van ami tényleg hiányozhat ilyen pl. a Full-Text Search, vagy a CLR, ha ezeket használjátok.
Én kérek elnézést!
Új hozzászólás Aktív témák
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Kupon kunyeráló
- Revolut
- AMD Navi Radeon™ RX 7xxx sorozat
- Ukrajnai háború
- Konzolokról KULTURÁLT módon
- Apple iPhone 15 Pro Max - Attack on Titan
- Hálózati / IP kamera
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Internet Rádió építése (hardver), és programozása
- További aktív témák...
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen