Klez Posted December 22, 2008 Report Share Posted December 22, 2008 Java, ko tu tur murgo par migraacijaam ??? mysql migreet ir vienkaarshi, MSSQL arii migreet ir vispaar vienkaarshi ... un gan jau ka citas dbvs arii ... un aplikaaciju parasti plaano (taa buus jsp, php, prel .... ) nevis uztaisa php un naakamajaa dienaa jau raksta jsp ... un tas kas der visam tas neder nekam .. Link to comment Share on other sites More sharing options...
v3rb0 Posted December 22, 2008 Report Share Posted December 22, 2008 un ko jūs visi par tām jsp aplikācijām - jsp ir nekas vairāk kā templeitu valoda, ja jsp konektējas pie db, tad tā jau ir kārtīga plānošanas kļūda. Link to comment Share on other sites More sharing options...
Java Posted December 22, 2008 Author Report Share Posted December 22, 2008 SQL visur ir līdzīgs! Pareizi? Tātad - teorētiski, nevajadzētu būt smagām problēmām db profesionālim migrēt pat lielu datubāzi no MySQL uz Oracle - darbs gan var būt laikietilpīgs gan. Klez - nu a ko darīt, ja gadās klients, kas grib tikai Microsoft un opensource - ninini! Un viņš ir gatavs par to maksāt! Sūtīsi 3 mājas tālāk šais krīzes laikos, jo tev aplikācija uzrakstīta php un tu ienīsti Bilu principa pēc? Nedomāju viss, darbs ir, pārrakstīsi līdzīgā stilā uz .NET, nomigrēsi MySQL datubāzi uz MS SQL Server un rullēsi zirgā. Link to comment Share on other sites More sharing options...
Aleksejs Posted December 22, 2008 Report Share Posted December 22, 2008 (edited) Java, pasaki vismaz, vai tas threads, ko devu ir pa tēmu. ;) Edited December 22, 2008 by Aleksejs Link to comment Share on other sites More sharing options...
andrisp Posted December 22, 2008 Report Share Posted December 22, 2008 Java, esi taču reāls. Tāda situācija ir tik ļoti neiespējama, ka nav vērts tādēļ iespringt. PS. Procedūru sintakse/iespējas starp DBVS var atšķirties diezgan spēcīgi. Link to comment Share on other sites More sharing options...
Delfins Posted December 22, 2008 Report Share Posted December 22, 2008 Vispār jau taisot lielas sistēmas konkrēti projektē - izvērtē visas nepieciešamības, variantus, iespējas. Konkrēti izvēlas vienu platformu un turās pie tās. Migrēšanu jāveic ar 100000% pārliecību, ka tā tiešām ir nepieciešama un vai tā atmaksāsies kaut vai tuvākā 1 gadā. Konkrēts piemērs no lielām ERP sistēmām - Axapta izmanto MSSQL/Oracle - tur tiek izmantota no bāzes tikai kā "krātuve", nav nekas no relations, ne view, ne procedūras. Daļēji atbalsta Oracle particionēšanu. Link to comment Share on other sites More sharing options...
Java Posted December 22, 2008 Author Report Share Posted December 22, 2008 Es esmu reāls un realitāte ir tāda, ka ir vajadzīga nauda par ko dzīvot, apmaksāt visus rēķinus, un, iespējams, svinēt Jauno Gadu. Šī realitāte var būt pietiekami sāpīga, lai pacenstos paveikt kaut ko vairāk arī, nekā pašam patiktos! Dzīve smaga, ko darīs. Link to comment Share on other sites More sharing options...
Ghenis Posted December 23, 2008 Report Share Posted December 23, 2008 Ja dikti gribas visu datu loģiku pārnest uz DB, rekomendēju jūzot PostGres dēļ spēcīgāka procedūru atbalsta (Piem. procedūras ir arī exceptioni etc. ). Es personīgi nevaru iedomāties, kā īzī to realizēt MySQL un arī, kā MySQL procedūrā vienkārši čekot tādu prastu lietu kā e-pasta atbilstību formai . Link to comment Share on other sites More sharing options...
marrtins Posted December 23, 2008 Report Share Posted December 23, 2008 Neiesaku MySQL šādām izvirtībām. Uzrakstīju pāris trigerus un procedūras, bet nu totāls pain in ass, salīdzinot ar Firebird vai Postgre. mysql migreet ir vienkaarshi, MSSQL arii migreet ir vispaar vienkaarshi ... Plikus metadatus varbūt, bet procedūras un trigerus? Link to comment Share on other sites More sharing options...
Java Posted December 23, 2008 Author Report Share Posted December 23, 2008 Ja dikti gribas visu datu loģiku pārnest uz DB, rekomendēju jūzot PostGres dēļ spēcīgāka procedūru atbalsta (Piem. procedūras ir arī exceptioni etc. ). Es personīgi nevaru iedomāties, kā īzī to realizēt MySQL un arī, kā MySQL procedūrā vienkārši čekot tādu prastu lietu kā e-pasta atbilstību formai . Hostingi daudz biežāk un vairāk atbalsta MySQL. Taisīt, lai iet tikai uz PostGre SQL būtu tas pats, kas taisīt teiksim skriptu uz Python, nevis PHP - ies ta ies, varbūt pat ātrāk, taču reti kurš hosteris atbalstīs. Protams, ja savs serveris, tad var visu kaut vai programmēt valodā XYU. Link to comment Share on other sites More sharing options...
v3rb0 Posted December 23, 2008 Report Share Posted December 23, 2008 (edited) nu paga, Tev takš vajadzēja migrēt uz visām iespējamām tehnoloģijām, jo klientam varbūt vajadzēs, tagad saki ka liksi to visu uz vidējo aritmētisko hostinga plānu. tad kāpēc migrēšanās kā prasība, ja produkcijas vide ir php/mysql un nekas cits? teicu jau overenginērošana, bet nu tam laikam visiem jāiziet cauri. Edited December 23, 2008 by v3rb0 Link to comment Share on other sites More sharing options...
Klez Posted December 23, 2008 Report Share Posted December 23, 2008 java, ja klients grib m$, tad klientam vajadzeetu būt spēcīgam argumentam. tas nekas ka vinsh tev met naudu pakalj un saka ka man vajag m$ ... arii uz mikrosoft IIS var php piedarbinaat un esmu pa visiem 100% paarliecinaat ka klientam ir vienalga kas apstraadaa datus (php,java,perls,) vinjam ir svariigs rezultaats. un datus paarbaudiit datu baaze nav praatiigi. piemeeram njemsim FMS apvārsni datubaazee ir 900 tabulas, 11 view`i un 24 procedūras. (un datubaaze manaa gadiijumaa sver 3409,13 MB) un es nedomaaju ka apvaarsni ir taisiijushi iesācēji. tā kā padomaa vai ir jeega db serverim uzkraut papildus paarbaudes utt ... Link to comment Share on other sites More sharing options...
Java Posted December 23, 2008 Author Report Share Posted December 23, 2008 (edited) Tu jau nepārbaudi vai dati ir valīdi, to pārbaudi pirms sūti tos vispār uz datubāzi. Datubāzē tu vienkārši veic visus selektus, kverijus un error apstrādi, kas no tiem izriet - procedūrās, trigeros utml. Tieši šis darbiņš būtu jāuztic mysql (šeit - datubāzes serverim), jo es saku - kāpēc php (šeit - server puses skriptam) ir jādara tas, kas patiesībā ir jādara MySQL - tas, ko patiesībā dara MySQL, runa ir par to, ka tu netaisi no php n-kverijus uz datubāzi, bet nodot sagatavotos datus procedūrai, kura atgriezīs rezultātu vai erroru - datu formā. Kur tev te ir datu pārbaudes ar datubāzi? Es tak teicu, ka vispirms php jāpārbauda vai dati ir valīdi, ko nodot datubāzei + to tips (int,string utml.) - tātad - datu pārbaude, kas attiecas uz php tiek veikta php, bet tā, kas attiecas uz MySQL - to veic MySQL. Rezultātā mēs iegūstam loģiskāku un labāk uzturamu programmas arhitektūru (vismaz kas attiecas uz šiem aspektiem). Runājot par citām tehnoloģijām un MS - tieši tā - gadās, ka klientam ir savs serveris un viņš vēlas izmantot tur tehnoloģijas, kas viņam labāk patīk. Lieta tāda, ka tiem, kam nepatīk konsoles un logu pētīšana, kas vēlas spaidīt ikdienā tikai Windows pogas un klikšķināt logus, tiem patīk tas IIS ar ASP un .NET. Viņiem ne pārāk interesē programmas teksts, viņiem patīk, ka ir sajūta, ka viņiem ir lietotāju ērtības plus MS "kvalitāte" jeb garantija par ko viņi samaksājuši (par to kvalitāti varētu vēl smagi pastrīdēties). Protams, nav viegli pārslēgties uz citu tehnoloģiju, bet ja tev ir zināmi pamati tai tehnoloģijā un ir pieredze uz to, tad vienkāršus un vidējus projektus vari uzņemties veidot. Principi jau paliek visur ļoti līdzīgi, atšķiras tikai valoda un prasības. Tiesa gan - php smagi atpaliek ar savām iespējām rakstīt absolūti sviestainu kodu kā newbie - Javā tik vienkārši to neizdarīsi - tai valodai ir krietni augstākas prasības pret cilvēka intelektu, kas to lieto - un līdz ar to, garantētais kvalitātes līmenis - augstāks, attiecīgi arī cena - augstāka. Piemēram, kāda veida funkcijas varētu un vajadzētu, manuprāt, darīt datubāzei: * constraintu (ierobežojumu) pārkāpumiem - jāatgriež errora msg vai arī tā numurs, kurš glabājas php array - tas vēl ir jautājums, kā labāk; * ja dati neeksistē, atgriež kur un kas neeksistē; * ja dati eksistē un ir nepieciešama iterācija - izdarīt to varētu procedūra, bet php atgriezt plain array; Visiem tiem messagiem jābūt šabloniskiem bez db specifiskās valodas un php var tos arī šabloniski tulkot, ja vajag. Ir skaidrība? P.S. Kas db logos neglabājas oriģinālie MySQL errori? Nafig tie būtu jāredz apmeklētājiem? No otras puses - tik un tā apmeklētājiem jāzin, kur ir errors! Nedomāju, ka tas ir labi ne no labā stilā, ne drošības viedokļa. Bet error-reporting sistēmai jābūt universālai un manuprāt, nebūtu godīgi, ja pilnībā apstrādāt MySQL errorus vajadzētu uzkraut uz nabaga php pleciem! Edited December 23, 2008 by Java Link to comment Share on other sites More sharing options...
Java Posted December 23, 2008 Author Report Share Posted December 23, 2008 P.S.S. Par to error reportingu - man vēl nav galējais slēdziens kā sakārtot to lietu... Bet fakts, ka procedūra var pildīt to pašu, ko attiecīgās php 50 rindiņas ir fakts un tā arī vajag. Link to comment Share on other sites More sharing options...
Ghenis Posted December 23, 2008 Report Share Posted December 23, 2008 Ar MySQL procedūru valodu būs stipri par īsu, lai varētu sabāzt puslīdz normālu datu loģiku datubāzē. Piezīme: Ir klienti, kam obligāta prasība ir tikai MicroSoft tehnoloģijas. Tā arī tiešā tekstā pasaka . Link to comment Share on other sites More sharing options...
Recommended Posts