← Uz sākumu

Casual thoughts

2005. gada 7. jūnijā, 46 komentāri

Tie, kas raksta tīru (X)HTML'u ir vai nu “birkotāji” (no “to tag something”, lai arī nav patiesi), vai “marķētāji” (no “to markup something”).

Skriptu veidotāji, kuri raksta iekš to PHP, vai kā cita tik pat interpretējama, ir “scenārijotāji”, vai “scenāriju autori”.

Specifiski par PHP. Weblapas ir risinājumi. Aplikācija. Skriptu kopums, kuri darbojas webservera vidē. To visu darbina PHP interpretators. To apskatīt var ar pārlūku. Teorētiski par korektu risinājumu var saukt ko tādu, kas strādā. Strādā tikai viss kopā. LAMP.

Python, Perl vai PHP? Kā intermediate starp backend un tā lietotājiem. Pieprasījumi un atbildes. Atskaites un statusi.

Safe deployment. Redundant un trustworthly risinājumi. Testi, testi, testi.

Tagad dīdos. Oracle vs MSSQL. Cena ir faktors. Performance arī. Advokātus nevajag. Vajag speciālistu aptauju. Head to head neder, jo tas pārvēršas balagānā. Grūti abstrahēties no preferencēm un tikt vaļā aizspriedumiem. Atzīt, ka nav pieredzes un aizvērt muti komentāriem, kas patiesībā ir tikai minējumi.

Brīžiem noķeru sevī domu, ka pietrūkst pieredzes. Bet esmu pārliecināts, ka izdosies. Bet tomēr ir bail.

Esmu izlasījis nenormālos kalnus ar case studies, technical specs, e-grāmatām, specifiskiem dokumentiem, idejām, plāniem, u.t.t. Tagad tas viss sāk lēnām līmēties kopā.

Patika teksts viena gara papīra beigās. Kaut kas līdzīgs šim: “To glue it all together you need to sleep on it. Or, at least, - to sit on it in a loo. Then come back and read me again.”

Tu atbildi augstāk redzamajam komentāram. Atcelt

Gravatar e-remit

2005. gada 7. jūnijā, plkst. 12:27

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.

Gravatar Livingston

2005. gada 7. jūnijā, plkst. 12:49

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?

Gravatar ulzha

2005. gada 7. jūnijā, plkst. 13:36

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

Trustworthy, nevis trustworthly.

Gravatar Mr.Venom

2005. gada 7. jūnijā, plkst. 13:42

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

Gravatar laacz

2005. gada 7. jūnijā, plkst. 13:45

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? :)

Gravatar misame

2005. gada 7. jūnijā, plkst. 13:49

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

Gravatar Kaklz

2005. gada 7. jūnijā, plkst. 13:49

laacz, izstrādātājs - MS

Gravatar Livingston

2005. gada 7. jūnijā, plkst. 14:51

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ē.

Gravatar Livingston

2005. gada 7. jūnijā, plkst. 14:55

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.

Gravatar hvz

2005. gada 7. jūnijā, plkst. 15:14

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 :)

Gravatar hvz

2005. gada 7. jūnijā, plkst. 15:15

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.

Gravatar DimanC

2005. gada 7. jūnijā, plkst. 15:34

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...

Gravatar dd

2005. gada 7. jūnijā, plkst. 15:40

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

Gravatar Livingston

2005. gada 7. jūnijā, plkst. 15:47

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).

Gravatar Livingston

2005. gada 7. jūnijā, plkst. 15:51

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

Gravatar hvz

2005. gada 7. jūnijā, plkst. 16:14

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.

Gravatar Livingston

2005. gada 7. jūnijā, plkst. 16:23

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.) :)

Gravatar Buu

2005. gada 7. jūnijā, plkst. 17:09

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ā

Gravatar DimanC

2005. gada 7. jūnijā, plkst. 17:27

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...

Gravatar Livingston

2005. gada 7. jūnijā, plkst. 18:31

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 :)

Gravatar watt

2005. gada 7. jūnijā, plkst. 18:59

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.

Gravatar bums

2005. gada 7. jūnijā, plkst. 20:23

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

Gravatar DimanC

2005. gada 7. jūnijā, plkst. 20:52

Livingston - paldies ;-)

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

Gravatar mefisto

2005. gada 7. jūnijā, plkst. 23:27

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. ...

Gravatar Lupus

2005. gada 7. jūnijā, plkst. 23:31

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.

Gravatar Knagis

2005. gada 7. jūnijā, plkst. 23:32

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.

Gravatar Lupus

2005. gada 7. jūnijā, plkst. 23:42

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 ;)

Gravatar Livingston

2005. gada 7. jūnijā, plkst. 23:57

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.

Gravatar Lupus

2005. gada 8. jūnijā, plkst. 00:06

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 :)

Gravatar null

2005. gada 8. jūnijā, plkst. 07:56

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.

Gravatar Livingston

2005. gada 8. jūnijā, plkst. 09:07

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.

Gravatar JIB

2005. gada 8. jūnijā, plkst. 13:18

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.

Gravatar e-remit

2005. gada 8. jūnijā, plkst. 13:50

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.

Gravatar Peeteriz

2005. gada 8. jūnijā, plkst. 14:59

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.

Gravatar Livingston

2005. gada 8. jūnijā, plkst. 15:32

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 :)

Gravatar Livingston

2005. gada 8. jūnijā, plkst. 15:39

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ē.

Gravatar Livingston

2005. gada 8. jūnijā, plkst. 15:44

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.

Gravatar aldis

2005. gada 8. jūnijā, plkst. 16:11

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.

Gravatar Livingston

2005. gada 8. jūnijā, plkst. 16:30

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???

Gravatar aldis

2005. gada 8. jūnijā, plkst. 16:34

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.

Gravatar e-remit

2005. gada 8. jūnijā, plkst. 17:39

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. ;)

Gravatar Livingston

2005. gada 8. jūnijā, plkst. 18:14

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

Gravatar Peeteriz

2005. gada 9. jūnijā, plkst. 09:40

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.

Gravatar Livingston

2005. gada 9. jūnijā, plkst. 18:23

Ā, 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 :)