MSSQL vs Oracle? Ņem PostgreSQL, bet ja tiešām gribi maksāt, ņem šo: http://www.sraapowergres.com/en/ - šis no Postgres attīstījies.

ti eto kuda temē ?

DB kāda mēroga risinājumam? 10 vienlaicīgi procesi, daļa no kuriem izmanto vienus un tos pašus datus? Plus vēl kaudze ar lietotājiem read/write režīmā? Vai DB g-kārt lasīšanas režīmā no dažām tabulām?

Kāds baklažāna/maģistra/doktora darbs?

Trustworthy, nevis trustworthly.

Strādāju ar MSSQL, pat Access man patīk labāk (: Oracle, manuprāt tīri ideoloģiski vairāk kotējas

Mr. Venom: Nav gluži tiesa. Par to kotēšanos. Un salīdzinot Access ar MSSQL man rodas jautājums - kas viņiem kopīgs? :)

ir, ir kopīgs - abi ir zināmā saistībā ar RDBMS :)

laacz, izstrādātājs - MS

Access nevajag pieminēt saistībā ar datu bāzēm. Advancēta peizīmju grāmata jā, bet DBVS ??

MSSQL jau ir nopietnāka alternatīva. Latvijas apstākļos var to izmantot, ja DB nav kritiska kaut vai viena iemesla dēļ - strādā tikai uz Win platformas, tikai uz Widows savietojamiem dzelžiem, bet windows dzelžus Latvijā neviens nopietni nesupportē.

Jebkurā gadījumā, vispirms vajag saprast, ko vajag realizēt ar DB palīdzību un tad izdomāt kā to var realizēt vienā vai otrā DBVS. Ja ir jautājumi par Oracle, labprāt atbildēšu.

Pirms izvēlēties oracle iesaku sīki iepazīties ar viņu licenzēšanas noteikumiem konkrētajai realizācijai. Lai nesanāk pirkt unlimited user licenci par nesaprātīgām naudām. Valsts iestādēm protams tas po :)

Pie iepriekšējā - kamēr ir jārunā par tehniskām lietām oracle pārstāvji ir ļoti pretimnākoši, kad sākas licenču lietas, tā atradīs 100 un vienu sīkumu, kā dēļ tev jāpērk visdārgākā licence.

par speciālistu sevi nenosaukšu, bet fakts - iekš LV, AFAIK, nav neviens projekts, kurš sekmīgi izmantotu visas vai lielāko daļu Oracle fīčas (neuzskaitīšu), kuras piedāvā oracle. pat nerunājot par fīčām - sekmīgu proejektu, kas izmantotu Oracle, ir ļooti maz... par to der izdarīt secinājumus. adminu prasmes, projektētāju pieredzes, pasūtītāju neizpratnes u.c. iemeslu dēļ.

par MSSQL - īsti nezinu, bet, šķiet, ka tur statistika ir nedaudz labāka. tobiš - vērtējot līdzšinējo statistiku, lācim mazāka varbūtība ar MSSQL izgāzties :-D

bet, kā jau citi še teica - viss ir atkarīgs no konkrētā gadījuma prasībām un vajadzībām.

p.s. ja jau projekts un vajadzība ir tik liels (to spriežu pēc vārdu Oracle/MS SQL), tad nopietns pasūtītājs prasītu nopietna analītiķa/izpētes grupas palīdzību, un tad šo jautājumu iekš laacz.lv blogā mēs neredzētu.

un vispār - jāiespringst vairāk, jānodefinē prasības, jāveic to analīze, un tad pretī katram konceptuālajam risinājumam (relational/document-oriented/object-oriented DBMS) jāvelk plusi/mīnusi. un tikai pēc tam var skatīties uz kādiem konkrētiem produktiem...

varbūt lācis vnk pie tējas uzmuģija šo postu tāpatvien :)

Ja datu apjoms ir tāds, lai sāktu domāt par datu particionēšanu, paralēliem pieprasījumiem, trasnportējamām tabulvietām, ja vajag vairākos pasaules reģionos nodrošināt pieeju 112 DB instancēm, ja vajag replikāciju un pieejas kontroli atsevišķu ierakstu līmenī, tad jā - vajag maksāt par Enterprise Edition un šīs iespējas par velti neviens nenodrošinās :)

Pretējā gadījumā var pirkt standarta versiju - ja lietotāji daudz, tad licenzēt uz procesoriem, ja lietotāju maz (named users - tad licenzēt uz minimālo lietotāju skaitu).

DimanC, cik bankās, telekomos un vispār lielos uzņēmumos ir atteikušies no Oracle par labu MSSQL ? :)

livingston - ir gadījumi, kad named users ir tiešām maz, bet oracle pārstāvji brēc ka nekā nebija, davai licenzēt uz procesoru, jo jums ir daudz lietotāju tomēr caur citiem procesiem.

Licenzēšanas noteikumos jau tas viss patiesībā ir atrunāts - ko un kad sauc par "Named user". Vairumā gadījumu gan ir izdevīgi licenzēt uz procesoru, jo, ja pieaug lietotāju skaits, nevajag pārmaksāt, tikai ielikt jaudīgāku procesoru. Un cerēt, ka tik drīz nepārstās ražot jaudīgus single core procesorus (jo dual core no Oracle viedokļa = 2 procesori utt.) :)

MSSQL ir pārāks:

• tas ir jūtami lētāks
• vieglāk instalēt un uzturēt (līdz zināmai robežai)

Oracle ir pārāks:

• imho PL/SQL ir ar daudz vairāk iespējām par T-SQL
• visādas tjūninga iespējas
• nav piesiets vienai platformai

Kopsavilkums: ja vien cenas atšķirība pret projekta budžetu nav acīmredzami pa labu MSSQL, tad ņemt to iekš kura vairāk pieredzes - tipa - izstrāde arī naudu maksā

Livingston - ok, mana negatīvā pieredze nāk no visādu DBMS pielietošanas pārvaldes organizācijās.

tādā gadījumā - man tīri interese - kas ir izstrādājis šo banku/telekomu DB (iet runa par LV)? zinu, ka varbūt komercnoslēpums, taču tās noteikti ir spēcīgas organizācijas, bet še, izskatās, lāčonkulis viens pats kaut ko grasās rauties...

DimanC, pie pārvaldes organizāciju IT projektu neveiksmēm jau nav vainojama DBMS izvēle. Pats zinu tikai vienu slavenu projektu, kuru taisīja un pārtaisīja daudzas vietējās un pat starptautiskas koderu kompānijas, bet projektu izgāza [bez]darbība. Lielajos uzņēmumos ir dažādi - ir varianti, kad vietējās IT kompānijas ir izstrādājušas visu risinājumu, ir sistēmas, kas no FoxPro pamazām izaug un tiek pārnestas uz spējīgāku DBMS, ir ļoti daudz risinājumu, kur Oracle izmanto DB līmenim dažādas specializētas aplikācijas, ko raksta simtiem cilvēku. Bet nu vienādi grūti vai viegli ir strādāt ar jebkuru DBVS. Nedomāju, ka MS SQL tabulu ir vieglāk uztaisīt par Oracle tabulu, tas pats ar indexiem utt. Bet cilvēki bez saprašanas var sabojāt visu :)

lācz,klausi manu pieredzi: mssql ir lielas sāpes. ir problēmas ar transakcijām: bloķējas ieraksti. pie oracle ir row-level locking, un viss kaifīgi rullē.

bez tam MSSQL nākamā versija būs tikai longhorn, bet oracle nepārtraukti attīstās, linux vai win vai solaris, viss viens.

to watt: nu nākošā sql servera versija būs šogad... kopā ar .net 2.0 un vēl visādām labām lietām

Livingston - paldies ;-)

tā jau ir ar to cilvēku (ne)saprašanu...

DimanC: http://www.cs.rtu.lv/stp/eiduks/eiduks.htm emmm, khm.

pārdomas MSSQL - man ir aerģija pret mazajiem-mīkstajiem MySQL - visiem ir ... bet ka uzliku uz sava luuznīša, likās ka tas sastingst Oracle - man nav naudas PostgreSQL - lietoju. Par brīvu un nevar just ka tas vispār kaut kādus resursus patērētu. Pēc būtības jaudīgāks par MySQL. ...

Interesata diskusija. Interesējamies par suņubūdu, nezinot vai pirksim kāmīti vai krokodīlu.

Ja DBVS sāk vadīt projektēšanas procesu, kaut kas nav kārtībā ar arhitektiem. Šeit palīdz sūdains miets. To pašu gribētu teikt par tiem brīnumbērniem kas elementārās klasifikatoru sistēmās (kas, pēc būtības, ir lielā puse valsts projektu) brēc pēc oracle kā vienīgā pareizā risinājuma.

ar oracle man pārāk liela saskarsme nav bijusi. bet ja tev nav specs, kas ar to māk darboties, tad jau instalācija būs riktīgi sāpīga. ar mssql tādu problēmu nav.

Mefisto, mani 2 centi (ja nu kas): MSSQL - visnotaļ pieņemams risinājums vidēja izmēra MSšopiem. Galvenā fīča - pazīstams pogu izvietojums administrācijas panelī (bet vispār, jā, lietot var. Tikai nevajag iespringt. Dažas labas fīčas, piemēram xml apstrāde rullz.) MySQL - jebkurš, kurš uzskata ka uz šī brīnuma var uzlikt kādu noslogotu produkcijas sistēmu (atskaitot LAMP web saitiņus) būtu jānošauj uz līdzenas vietas. Vai arī nē, tā būtu viņam pārāk viegla nāve. Oracle - Ja tu zini cik viņš maksā un sāc skatīties vai varēsi atļauties licenzi, 99.(9)% garantija ka tu gribi to pielietot projektā kur pēc viņa nav vajadzības. PL/SQL ir sapnis, tehniskais atbalsts strādā. Tie kas atļaujās sevi nosaukt par oracle pazinējiem parasti vismaz relāciju datubāzes pat pazīst. PostgreSQL - cienīgs risinājums vidēja izmēra projektiem ja ir alerģija pret MSbodīti. Nav logu. Gemorojs administrācijā. Bet strādā. Un pat labi. Izejas kods gan izskatās pēc obfuskācijas konkursa fināla dalībnieku trenniņa.

Tās nav vienīgās ;)

Lupus, man gan šķiet, ka ļoti daudzos gadījumos pēc iepazīšanās ar cenu no Oracle mēdz atteikties nenopietni interesenti. Mazi projekti, kurus grib "ierakstīt" zem 10K Ls vienkārši nevar atļauties Oracle licenzes. Es gan pieņemu, ka ir daudz tādu, kas izmanto Oracle, bet nekad nav domājuši par to maksāt - par šo kategoriju faktiski neko nezinu. Un var būt otrādi - cilvēki nenovērtē prasības, izvēlas kaut kādu mazjaudīgu DBVS, uztaisa sistēmu, padzīvo gadu un secina, ka ir par īsu. Un ka visas problēmas nevar atrisināt ar atmiņas iepirkšanu un jaudīgāku procesoru. Bet fakts tāds, ka dati dzīvo ilgāk par aplikāciju. Aplikāciju dizains mainās, likumdošana mainās un biznesa loģika mainās, bet datus turpina izmantot atkal un atkal.

Livingston - par to jau arī es runāju. Ja tu gribi lietot Oracle, bet tevi rausta viņa izmaksas, visticamāk ka tu esi no tiem puskokā lēcējiem kuriem tiešām kaut kāds MSSql labāk noderētu.

Lai arī no otras puses - savā ziņā tā jau ir standartizācija, fakts ka mūsu valsts var atļauties visur lietot Oracle :)

Pēc savas pieredzes varu teikt, ka MSSQL ir ļoti ok mazam un vidēji lielam datu apjomam pie mazas 'konkurences'. DB ar 10-20 tabulām ar 10k-100k ierakstiem strādās vairāk vai mazāk vienādi gan uz Oracle, gan MSSQL. Šeit imho noteicošais ir cena. Ja ir zināms, ka kādreiz datu būs vairāk, ir vērts padomāt par Oracle vai, ideālā gadījumā, par neatkarību no dbms branda.

Par neatkarību no konkrētas DBVS var domāt, bet ar mēru. Man šķiet, ka pasaulē ir uz rokas pirkstiem saskaitāmas aplikācijas, kas labi strādā ar lieliem datu apjomiem un ir pilnībā neatkarīgas no konkrētas DBVS. Gadījumi, kad tiek rakstītas speciālas versijas priekš Oracle, MSSQL, MySQL utt. neskaitās.

Stelle no dzives: ERP Axapta (sensenos laikos izstradaja Danji, pedejos 3-4 gadus iet zem MS ka Microsoft Business Solutions) iet gan uz MSSQL gan Oracle. Jautajums labi vai slikti ir atklats (es domaju ka abas realizacija labakaja gadijuma ir viduvejas), bet klienti lieto abas gadiem.

Latvija: 90% instalacijas ir MSSQL, Orcle - 10% Man lielaka drosi zinama MS SQL instance ir ~30GB datu, 60 online useri, >10M ierakstu. Oracle ~20-30GB ~140 onlne useri ari nnM ierakstu.

Pasai Axatpai 1-2k tabulu. Aplikacija nav unicode, bet pseido unicode suports Orcale ir labaks (~1-2% performance penalty, MSSQL 7-10%)

Uzlikt un apkalpot vienkarsu MSSQL instanci ir DAAUDZ vieglak, Oracle toties var partjuneties liks, bet parasti daudz vairak jatjuno ir aplikacija, nevis DB.

Isteniba gaumes jautajums. Man personigais viedoklis, kamer abas DBVS nav sasniegts limenis, kad uzduras tiesam kaut kadiem limitiem, tad objektivu izveli nevar veikt.

Principa lidzogos apstaklos cenas ir ~ lidzigas, galu gala konkurejosi produkti (pamat MS letaks). Abiem ir letie varianti mazam instancem (10 useri) un uz augsu.

Sore MySQL un Postgres neko nemaku tiekt. Vel jau ir citas alternativas, piem, Interbase utt. ODB ari ir interesanti varianti.

Startp citu - Postgres sākot no 8. versijas ir arī Windows versija. Lielai daļai projektu pietiktu tieši ar šo, jo ir gan pieejamas transakcijas, gan vēl dažādas tradicionāli nepieciešamas figņas.

Par Oracle supportu - parasti viegli dabūt atbildes uz jautājumiem, kuru atbildes var atrast Metalinkā, vai citur inetā. Bet tikko ir specifiskas fīčas, tā bieži sanāk pašasm atrast risinājumu ātrāk, nekā atbildi no supporta. Turklāt ne vienmēr supporta atbilde ir, ka to var - bieži viņi pasaka, ka kaut ko nevar, bet pats jau to esi izdarījis. Tad pagrūti atkauties no viņiem, jo viņi ļoti grib zināt pareizo atbildi. Iemesls tam, ka daudzi neizmanto visas Oracle fīčas - bieži tās fīčas normāli strādā tikai Powerpoint prezentācijās. Tāpēc daudzi pagaida, kamēr citi sāks lietot. Dažkārt konsultantu ieteikumi priekšniecībai ir tādi, ka gribas viņus aiz ausīm atraut šurp, un likt pašiem panākt, lai tas viss strādā.

Un vēl - ja runā par salīdzinājumiem. Lai arī cik tas nebūtu dīvaini, ja vienkārši jāizanalizē dati dažās vienkāršās plakanās tabulās no viena lietotāja, gan Oracle, gan MSSQL, gan pērējie konkrēti zaudē vecajam labakam Fox 2.6 for Windows! (Pārbaudīts praksē). Vienīgi tas jāsapačo, lai uz jaunajiem procesoriem nekaras.

Man sanaak straadaat ar data warehouse, kas ir no MSSQL datubaazeem, lielaakaa no taam 50M ierakstu, 50 gb. Toolji straadaa, serveris straadaa, suudziibu iipashu nav. Pirms tam bija risinaajums uz oracle (tad bija apm 3x mazaaki izmeeri datiem), no kura atteicaas licenchu izmaksu deelj.

Bija probleema ar index file corruption, jo nogljukoja straava un RAID; par kuru mums techsupports ieteica izeksporteet datus un paarinstaleet serveri - ko beigaas arii izdariijaam.

JIB, Axapta ir ĻOOOOTI slikts piemērs. Tur tiek izmantotas TIKAI tabulas un primitīvi indexi. Netiek izmantoti trigeri, pat ne konstrainti. Vismaz 2.x versija, varbūt pēdējas versijās ir kas mainījies. Axapta on Oracle tjūninga iespējas? Ļoti minimālas, optimizēt darbu ar redo, pamainīt tabulvietu parametrus (ha, visi objekti sabāzti 2 tabulvietās - viena indexiem., otra tabulām), vākt vai nevākt statistiku, lai ietekmētu izpildes plānus. Pārējais viss ir black box un mainīšanai nepakļaujas, lai nezaudētu tech. atbalstu :)

to e-remit: Supportam jau rokas ir diezgan sasietas. Ir daudzi risinājumi, kurus oficiāli neatbalsta Oracle un nevar vieglprātīgi ieteikt klientam izmantot, piemēram. dažādus underscore parametrus, lai atrisinātu kādu problēmu. Par tām fīčām - uz Powerpointa strādā viss un visim, bet kas attiecas tieši uz RDBMS (nevis Applications, iAS utt.), tad IMHO lielākā daļa tiešām strādā arī dzīvē.

to Peeteriz: A MSSQL'am ir Discoverer? :)) Otrs produkts no Oracle, kas man tiešām patīk.

Kuras kompānijas supports Tev index failu korupcijas dēļ lika izeksportēt datus un pārisntalēt serveri? :)) Izklausās diezgan līki.

Piekrītu daudziem iepriekš rakstījušajiem, arī tiem, kas apgalvo, ka argumentētu ieteikumu bez papildus info sniegt tomēr pagrūti. Tāpēc no manis pāris vispārīgi tipi:

1. Ja cena ir faktors, varbūt ir vērts palūrēt uz SQL Server Express Edition (http://lab.msdn.microsoft.com/express/sql/), kas ir/būs par brīvu un kas release modē parādīsies šī gada beigās (tagad var apskatīties CTP un betas). Supportē stored procedūras, 1 CPU, 4GB uz diska un 1GB RAM - varbūt noder.
2. Ja performance ir faktors, tad tas, ka Oracle nebloķē SELECTus, kas nolasa tajā brīdī modificējamus ierakstus, ir pluss, ja notiek ilgas transakcijas, kurās maina datus. (wattam - row locking SQL Serverī ir jau no 7. versijas, bet domāju, ka problēma ar concurrent lietotājiem radās tieši šīs SELECTu bloķēšanas dēļ).
3. Ja patīk pašam visu konfigurēt, tad Oracle; ja gribas, lai viss ir vienkārši, tad MS SQL. Atkarīgs no tā cik svarīgas ir supporta, uzturēšanas izmaksas. Sevišķi kaifīgi ir instalēt Oracle uz nesupportēta Linuxa.
4. Ja izmaksas ir svarīgas, tad Oracle var uzlikt uz Linuxa, bet MS SQL būs jāpērk Windows serveris un CALi. Lai gan supportēts Oracle ir uz SUSE Enterprise un RedHat Enterprise un tie par maksu. Atkarīgs no organizācijas, kurai tiek taisīts risinājums - daži tomēr vēlas DB izstrādātāja supportu.
5. MS SQL nāk līdzi vismaz kaut kādi tūļi DB un SP izstrādei (kaut gan tie arī nav paši ērtākie, bet ER modeli varēs uzzīmēt un SP varēs uzrakstīt), Oracle parasti vajag "iegādāties" trešo pušu rīkus.
6. Ja izvēlies MS SQL 2000, tad tam bez tipiskā Standard Edition ir arī Workgroup edition, kas, protams, lētāka, bet kurā ir visas vajadzīgās fīčas (bez OLAPa, kas normāli nav vajadzīgs).
7. Oracle gadījumā jāizvēlas Standard Edition One, ar kuru arī vajadzētu pilnībā pietikt, ja nav mega DB.

Un tagad pats galvenais: nekad visu nevar paredzēt - tāpēc iesaku veltīt kādu nedēļu, uztaisīt mazu pilotu un paskatīties, kas un kā ar vienu DB un ar otru DB pie prognozētajiem datu apjomiem un sarežģītākajām darbībām, kurām svarīga performance. Oracle serveri var nokačāt bez maksas no OTNa, ar MS SQL 2000 laikam grūtāk, bet gan jau kaut kur var dabūt. Bieži vien izvēle būs atkarīga ne tikai no DB iespējām, bet arī no:

1. tā, kā uzrakstīti DB adapteri izvēlētajā Intermediate līmenī (PHP, Perl, Python)
2. no programmētāju līmeņa un pieredzes ar vienu vai otru DB (tas varbūt pat svarīgāk!!!). Šīs lietas var atklāt tikai tad, ja padarbina pilotu. Labāk ir uz vājākas, bet zināmas DB, uztaisīt pārbaudītu risinājumu, nekā uz labākas DB izdarīt tā, kā uz šīs DB tas nav paredzēts. Ja projekts nopietns, tad šī sākotnējā izpētei veltītā nedēļa atmaksāsies.

Sevišķi kaifīgi ir instalēt Oracle uz nesupportēta Linuxa.

Bet to var izdarīt un bez vai ar minimālām problēmām, ja vien neizvēlas kaut kādu baigo eksotiku.

Par 5. punktu vispār žoklis atkārās ... Designer, Developer, JDeveloper, Discoverer, warehouse Builder ir 3rd party izstrādes rīki???

izdarīt var visu. par to jau neviens neko nesaka. bet salīdzinot ar MS...

par 5. punktu atzīstu savu kļūmi. nez kāpēc neatcerējos, ka arī developeru rīkus var nokačāt bez maksas no OTNa.

laacz, atzīsties beidzot, kam Tev tas pasākums vajadzīgs?

zināju vienu, kurš uzlika Oracle (kaut kādas agrākas versijas) uz Slackware (pēdējām versijām tādas problēmas vairs nava). Supports gribēja par visu varu piespiest likt Redhat, a šis paņēma un pielaboja Javas instalāciju, un viss aizgāja.

P.S. kāds ir darbojies ar Oracle SCM? Reāls onānisms, līdz iemanies ar to darboties. ;)

Laacz štuko, ka vajag piezīmju grāmatiņu, nevar izlemt par DB ... :D

Ne es uz to supportu zvaniijos :)

Nu probleema taada, ka MSDN bija 'known issue, no known workaround', un ar visiem tiem vizuaalajiem management tooljiem ar to indeksfailu pilniigi neko izdariit nevareeja (ne sarepairot, ne izdzeest nafig), vislaik errormessage par probleemu. Supports esot ieteicis paarinstaleet, un taa ka mums jau bija ieplaanota migraacija uz lielaaku dzelzi, tad vienkaarshi paarmigreejaam aatraak.

Ā, tas bija ar MSSQL serveri ... tad cita lieta. Būtu ļoti izbrīnīts, ja vajadzētu pārinstalēt Oracle softu, lai atjaunotu indexus :)