Jump to content

DB izvēle


piekuns18
 Share

Recommended Posts

Sveiki.

Tiek plānota datubāze, kura nākotnē varētu saturēt tabulu ar 100 miljoniem ierakstu.

pati datubāze saturēs ~10 tabulas

Ir doma izvēlēties mysql. Vai tā ir ciešama izvēle vai tomēr izmantot teiksim: postgres,oracle,mssql?

Noteikti, ka mssql un oracle ir daudz jaudīgākas, bet vai uz tik lielu ierakstu skaitu ir kāda acīmredzama atšķirība datu ieguves laika ziņā?

varbūt kāds ir kaut ko tamlīdzīgu testējis savā praksē?

Link to comment
Share on other sites

10 tabulas - baigi maz. Kaut kāda pavisam primitīva veblapiņa izklausās. Praksē uzskaites sistēmas mierīgi iebrauc 50..100..150 tabulās, kad apaug ar vajadzībām.

 

Kolēģi daudziem miljardiem ierakstu faktiski real-time portālam izmantoja TokuDB iekš MariaDB un paralēli Redis. Nodalot, ko tad īsti vajag glabāt relācijās un ko - kā key/value ierakstus. Protams, ka bija šārdošanās visu laiku. Protams, ka bija māsteri/sleivi klāsterī.

Nebija tā, ka iestum visu vienā lielā tabulā un ceri uz 0.0001ms garantētiem rezultātiem uz 5400rpm cietņa pie 100mio ierakstiem un 512MB RAM patēriņa un 1000 vienlaicīgiem klientiem. Bet uz Oracle/MSSQL pat netaisās pāriet, laimīgi dzīvo, bremžu nav.

Link to comment
Share on other sites

Ierakstu skaitam db izvēlē nav lielas nozīmes. Svarīgi ir tas, ko ar tiem ierakstiem Tu taisies darīt. Pilno pārlasi miljons ierakstiem apmēram vienādi ilgi veiks visas DB

 

Oracle ir ļoti dārgs risinājums, bet ļaus taisīt visādus trikus ar pieejamību, slodzes dalīšanu, backupiem, kriptēšanu, monitorēšanu, administrēšanu utt. 

 

Ja sistēmā vēl nav neviena ieraksta, tad izvēlies mysql/postgre. Kad būsi sasniedzis griestus, domāsi, kur migrēt.

Link to comment
Share on other sites

Oracle ir daži ļoti debili ierobežojumi, kuri pamatīgi traucē normālas db izstrādei.

Link to comment
Share on other sites

MySQL Vai Postgres !

Postgress ir ritīgi powerfull datubāze !

 

Nevajag Firebird - nav neviena jēdzīga iemeslu to izvēlēties.

Man ir pieredze ko par mazu nenosauksi - nepatīk, nesaskatu nevienu plusu.

 

Oracle vispaŗ ir kaut kāds arhaisms un samurgojums. Vienkāršas lietas jādara caur pēcpusi un brīžiem neatbalsta pašsaprotamas lietas.

 

MSSQL navv slikta bāze, bet atkal jau nav īsti neviena iemesla izvēlēties to nevis PostgreSQL. J nu vineīgi ciešāka savietojamība ar M$ vidēm, bet arī ar Postgresu un MySQL neesmu novērojis savietojamības problēmas.

 

PostgreSQL ir dikti laba, spēcīga un bez maksas, ko nevarētu tiekt par MSSQL un Oracle.

Link to comment
Share on other sites

Oracle pieturas pie ideoloģijas, ka jo sarežģītāks produkts, jo vairāk varēs nopelnīt uz supportu un apmaācībām.

Iespējams tieši tāpēc nav visādu ērtu komandu/šortkutu, kā show databases; show tables,create db LIMT, utt.

Es protams saprotu, ka īsti vīri skujas ar cirvi vai vismaz sasistu alus pudeli, bet nu tomēr...

Un to saku es, kā cilvēks kurš Unix-like shelā jūtas tīri labi un nealkst lai visur būt Click-Click.

 

Tas, ka softs ir sarežģīts to nepadara par baigo kvalitātes etalonu - taisni otrādāk.

Jā, mana Oracle pieredze un zināšanas varētu būt lielāka. Taču nav arī tā, ka neko no viņas nemāku. Ir kāds brītiņš mazāku sistēmu un ir viena sirsnīgi liela DB uz ~7TB(Tur tiek glabāti arī BLOBi, tāpēc tik drastisks izmērs). Tur gan ne visu daru es viens.

Jā man pat uz 1TB neviena Postgres bāze nav. Nevaru pateikt, kā perfomētu Postgres. Taču ar Oracle NEĒRTUMU es saskaros ik dienas, ik uz soļa.

No saviem koderiem es arī nedzirdu labus vārdus par Oracle.

Link to comment
Share on other sites

ronalds, katram savas problēmas, pats tagad uz mysql domāju risināt Deadlock situāciju  ^_^

Labots - HTC
Link to comment
Share on other sites

100 milj ierakstu nav pārāk liela DB. beigu beigās viss reducēsies uz roku taisnību un galvas skaidrumu, nav nozīmes kāda DB. Ja Tu plāno visus 100milj vienkārši  sagrūst vienā lielā tabulā, tas gan jau ir ceļš uz elli. visticamāk.

 

Kas attiecas uz oracle - viņu alkatība ir neaprakstāma  un kā jau biedrs MIG teica - nekāds kvalitātes etalons tas vairs sen nav. Par licencēšanu - ieliekot VM VMWARE poolā vajag pirkt licenci uz visiem virtualizācijas hostiem pa pilno uz visiem CPU.  Vispār daudzos lielajos kantoros cilvēki ir sākuši strādāt lai no oracle atkratītos vai vismaz radikāli samazinātu viņa lietošanu - tas prasīs iespējams 10 un vairāk gadus, bet process ir sācies.

Link to comment
Share on other sites

Emm.. laikam būšu minoritāte. Oracle maksā par suportu. Pati DB nemaksā īpaši dārgāk par MSSQL tādam pašam pielietojumam. Oracle lielais pluss - normāli debugojama servera puse, nav bremzes situācijās, kad MSSQL ir vienkārši PĪ. Oracle neļauj darīt daudzas lietas... tikai tāpēc, ka projektētājs ir kaut ko salietojies un tas pēc būtības NEDRĪKST darboties. Toties MSSQL viss darbojas, tikai lēēēēēni... MSSQL pat mūsdienās Servera puses debugošana ir bērnu autiņos. Tieši tāpat kā lietas, ko Netware piedāvā jau seeen, jaunie Win servaki vēl mocās. Ja kas, jo nopietnāks risinājums, jo vairāk prasās lietot servera puses fīčas. Ar Oracle un MSSQL pieredze > 20 gadi...

 

Any way, tēmā aprakstītajai DB derēs arī opensorcīgie varianti, par kuriem biedri jau iepriekš minēja :)

Labots - rubb
Link to comment
Share on other sites

Skaidrs par Oracle nepilnībām, nebiju lidz šim to baigi uztvēris kā trūkumus. Man kā orāklistam citās DB atkal kaut kas cits liekas neērti/nepatīk utt, bet nu tas gan jau vairāk pieraduma jautājums. Un velns nav tik melns kā viņu mālē arī $$$ ziņā...

Anyway vienalga nestādos priekšā kā ar opensource risinājumiem var uzturēt biznesam svarīgas sistēmas gadījumā, ja kaut kas notiek ar pašu DB - Oracle gadījumā supports pa tiešo no softa izstrādātāja (protams vēl jautājums vai kaut ko atrisinās sapratīgā laikā), bet kam prasīt atbildību postgresql gadījumā :) Bet nu labi - gan jau var dabūt komerciālu suportu arī tur, jautājums tikai cik maksā un kādi nosacījumi.

 

Par tēmu un offtopic reizē - neviens nav pieminējis NoSQL :)

  • Patīk 1
Link to comment
Share on other sites

Supports tāpat neaizvietos, ne stabilus dzelžus, ne rezerves kopijas.

 

Tāpat supports, visticamāk, neribēs čakarēties ar softu/aplikāciju piešķilšanu uz jaunākas Oracle versijas un citas līdzīgas bēdas. Tur būs jāmokās pašam, vai jau atkal, kaut kas stipri astranomisks jāmaksā.

 

Ir daudz dzirdēts viedoklis, ka OpenSource produkti nav izmantojami, jo redzi tur aizmugurē nav supports un nav kam paprašit atbildību.

Tak izlasiet licenzes līgumus - neviens, nekad, neparko nenes atbildību !

 

Katrā ziņā par Oracle man bija vismaz 10 reizes labāks iespaids, pirms es ar to sāku ņemties.

 

Par ērtumu - nu Oracle defaultā komandriunda(Shells) man liekas neērtēks par Postgresa. Postgresam tur viss ir ļoti eleganti un ērti nostrādāts.

Link to comment
Share on other sites

nebiju lidz šim to baigi uztvēris kā trūkumus.

 

 

Piemēri no manas prakses - vajag rēķina rindas numurēt, lai varētu viņas sakārtot vēlamajā secībā.

 

Citās db iekš trigera before post tabulai REKINI_PRECES

IF NEW.NPK IS NULL THEN

   SELECT MAX(NPK)+10 INTO :NEW.NPK FROM REKINI_PRECES WERE REKINS_ID=:NEW.REKINS_ID

 

Viss! Viena rinda! Oraclem - mutating table error - jātaisa satment limeņa trigeri, papildus pagaidu tabulas, beigās ļoti sarežģīts un nepārskatāms kods sanāk....

 

Nākošais. Kā izrādās oracle foreign key nenozīmē ka tiks automātiski indekss uztaisīts! Grūti iedomāties kāpēc tā, jo pēc sql loģikas kur foreign key, tur vajag indeksu. Bet nu labi, pieņemsim.... Pats smieklīgākais ir, ka db nestrādā normāli ar vairāk kā vienu  lietotāju, ja ir fk bez indeksiem! Viens useris sāk labot rēķinu, sākas tranzakcija. Kamēr viņš tranzakciju nav pabeidzis, jebkurš citas tranzakcjas update ar rēķiniem saistītās tabulās gaida kamēr pirmā tranzakcija tiks pabeigta - vienkārši gaida, ne kļūdas paziņojumu, ne timeoutu! Ja viens useris attaisa iekš gui kādu rēķinu uz labošanu un aiziet pusdienās - visam ofisam darbs apstājas! Sataisot bāzē visiem fk indeksus šis efekts pazūd!

 

Un vēl ir kaudze ar kaitinošiem sīkumiem, kas mākslīgi sarežģī kodu, padara to nelasāmu...

Link to comment
Share on other sites

Mezavecis

Vispār DB izvēli balstīt uz ierakstu skaitu nav objektīvi. Arī tajā pašā MySQL var būt miljardiem ierakstu un nekas nebremzēs, ja neko sevišķu ar šo tabulu nedara. Protams, ja vajadzēs full-text search, blobos pēc bildes atpazīt cilvēku, lietot trigerus, taisīt lielus reportus, meklēt saistītajās tabulās, kur vismaz 100 kolonnas, tad izvēle var būt izdevīgāka citā virzienā. 

  • Patīk 1
Link to comment
Share on other sites

Par tēmu un offtopic reizē - neviens nav pieminējis NoSQL

 

ja? starp citu, šitos noskaties tīri redzesloka paplašināšanai.

 

sākot no 15:50 statistika un pielietojumu apspriešana.

un 

Labots - usver
Link to comment
Share on other sites

Autors tā arī nav pateicis, ko taisās tajā db glabāt un ko ar datiem iesākt. Var gadīties, ka labākais risinājums ir parasts teksta fails :)

 

Bez fīčām, cenas un performances vēl ir vērts apdomāt esošo cilvēku zināšanas. Ja nav speciālu apsvērumu, jāizmanto, tas kas ir vispazīstamākais. Tad nebūs ieberzienu ar zemūdens akmeņiem neprasmīgi lietojot kaut kādu pārāko tehnoloģiju.

Link to comment
Share on other sites

Es +- zinu NoSQL spēcīgās un vājās puses.

 

Tas komentārs bija tāds tāpēc, ka pirmajā postā autors prasīja relāciju DB, bet iespējams to nemaz nevajag...

 

 

Par pārējo - jā, Oracle ir mīnusi, bet tāpat taču ir arī citām DB. Un lielākā daļa mīnusu tāpat ir pieraduma jautājums, pārejot no citas DB.

Labots - Biete
Link to comment
Share on other sites

piekuns18

Nu man principā vajadzēja zināt vai ir jēga ņemt Oracle vai MS SQL. Katru dienu pa nakti notiks DB iztīrīšana un pāris miljonu ierakstu imports. Ar kuriem pēctam vajadzēts taisīt dažādus pārskatus iekš web. Paldies par atbildēm izskatās, ka ar MySQL nebūs nekādu problēmu. 

Link to comment
Share on other sites

Katru dienu pa nakti notiks DB iztīrīšana un pāris miljonu ierakstu imports.

 

Nu a kā imports notiksies? Tīrs insert vai tomēr insert un ja eksistē tad updeito esošo / dzēš lieko? No kurienes tiks veikts imports? Imports tiks veikts vienā tabulā vai vairākās un tās sajūgtas ar keyiem? Varbūt tomēr tiešām pārskatiem apstrādāt tikai failus, vai datubāzē saglabāt to informāciju, kas būs pārskatā? Nevienā pašā brīdī neesi norādījis neko, kas būtu vajadzīgs, lai izvēlētos pareizāko risinājumu. Šķiet, ka tomēr vajadzētu padalīties ar vairāk informācijas nekā "100 miljoni ierakstu"

 

Jebkurā gadījumā - pareizākais risinājums būs tas ko pats vislabāk pārzini (ja pats taisies taisīt)

 

Pēc pašreizējās info, sanāk moments: gribu dārgu auto, tur tiks ielieti 60L degvielas, ko iesakat. Ā, tomēr arī var piedāvāt bezmaksas auto... 

Labots - HTC
Link to comment
Share on other sites

piekuns18
Katru dienu pa nakti notiks DB iztīrīšana un pāris miljonu ierakstu imports.   Nu a kā imports notiksies? Tīrs insert vai tomēr insert un ja eksistē tad updeito esošo / dzēš lieko? No kurienes tiks veikts imports? Imports tiks veikts vienā tabulā vai vairākās un tās sajūgtas ar keyiem? Varbūt tomēr tiešām pārskatiem apstrādāt tikai failus, vai datubāzē saglabāt to informāciju, kas būs pārskatā? Nevienā pašā brīdī neesi norādījis neko, kas būtu vajadzīgs, lai izvēlētos pareizāko risinājumu vajadzētu padalīties ar vairāk informācijas nekā "100 miljoni ierakstu"

 

ķipa tavi nosauktie lielumi ir no savra izvēloties DB? Man pēc komentāru sniegtajām atbildēm radās iespaids, ka DB izvēle ir svarīgāka pie daudz nopietnākām sistēmām un lietojumiem. + Es vispār aprakstiju, kā notiksies darbība iepriekšējā komentārā. Es neko par update un dzēšanu neminēju, ne tā?. Arī cik tabulas būs es rakstiju. Nu ja tev kaut kas vēl nav skaidrs. Droši jautā.

Labots - piekuns18
Link to comment
Share on other sites

"Es neko par update un dzēšanu neminēju, ne tā?"

 

Tu arī neminēji, ka 100 miljonu rowu imports un datu sagatavošana pārskatiem notiks reizi naktī līdz ar to uzskatīju, ka izlaidis esi arī `update`, tāpat arī neesi minējies aptuveni ar cik gb lieliem datiem nāksies strādāt, vai tie būs 5Gb vai 50Gb ko importēt per night, eksistē arī  interesanti limiti atkarībā no os,db veida.  Lai vai kā - veiksmi projektā.

Link to comment
Share on other sites

Livingston

100m ierakstu? Cik liels būs ieraksts? 80 baiti vai 200k ?

 

Par Oracle trūkumiem - nu ja kādam svarīgāk ir iespēja ierakstīt "show db", nekā iegūt normālu ātrdarbību operējot ar vairākām tabulām, tas ir prioritāšu jautājums :)

 

Starp citu, par godu MySQL faniem Oracle jau kādu laiku arī atbalsta LIMIT selektos.

 

Ja paredzams, ka dati ielīdīs 11GB datu bāzē, tad visiem iesaku izmantot bezmaksas Oracle XE versiju.


P.S. ja importējamie dati ir CSV vai kaut kas tamlīdzīgs (visticamākais, ka ir), tad tos vispār nevajag importēt - taisa external table uz CSV failiem, veic analīzi, rezultātus ilgstošai uzglabāšanai saglabā normālā DB un nodropo external tables.

Importēšana, kam seko dzēšana būtu lieka laika tērēšana.

Link to comment
Share on other sites

 

 

nekā iegūt normālu ātrdarbību operējot ar vairākām tabulām

 

Cik ir strādāts ar dažādām DB, tad dramatiskas ātrdarbības atšķirības nemanīju! Es runāju par to, ka oracle ir kaudze ar vēsturiski iegājušām nepilnībām, kas pamatīgi traucē! Tas pats trigeru izmantošanas ierobežojums, jeb mutating table error jau pats par sevi ir ko vērts! Uzskatu ka šis ir pilnībā pietiekams iemesls, lai oracli atmestu kā šķiru jebkuram jaunam projektam!   

 

 

 

tad visiem iesaku izmantot bezmaksas Oracle XE versiju

 

Aha - izmanto tikai vienu kori un 1GB ram -  tiešām lietojami īpaši pie lielām bāzēm :D :D :D !  

Link to comment
Share on other sites

Livingston

 

 

Cik ir strādāts ar dažādām DB, tad dramatiskas ātrdarbības atšķirības nemanīju! Es runāju par to, ka oracle ir kaudze ar vēsturiski iegājušām nepilnībām, kas pamatīgi traucē! Tas pats trigeru izmantošanas ierobežojums, jeb mutating table error jau pats par sevi ir ko vērts! Uzskatu ka šis ir pilnībā pietiekams iemesls, lai oracli atmestu kā šķiru jebkuram jaunam projektam!
 

 

Tā nav nepilnība pati par sevi, bet gan situācija, kurā var nonākt, ja īpašā veidā tiek izmantoti Oracle trigeri. Daudzās citās datu bāzēs situāciju nevar atkārtot, jo ir pārāk daudz ierobežojumu uz trigeru izmantošanu. 

 

 

 

 

Aha - izmanto tikai vienu kori un 1GB ram -  tiešām lietojami īpaši pie lielām bāzēm !

 

Šis ierobežojums ir TIKAI Orace XE BEZMAKSAS versijai, kam arī lietotāju datu apjoms ir ierobežots līdz 11GB.

 

Pats esmu daudzus gadus strādājis ar daudzu terabaitu datu bāzēm, tagad ir desmitiem klientu ar simtiem GB un TB DB un visas tās ir Oracle datu bāzes kur uz tabulām ir daudz trigeru un kurās realizēta sarežģīta loģika.

 

 

Dramatisku atšķirību ātrdarbībā nevar redzēt tikai tad, ja bāzes ir mazas un pieprasījumi triviāli. 

Link to comment
Share on other sites

piekuns18
P.S. ja importējamie dati ir CSV vai kaut kas tamlīdzīgs (visticamākais, ka ir), tad tos vispār nevajag importēt - taisa external table uz CSV failiem, veic analīzi, rezultātus ilgstošai uzglabāšanai saglabā normālā DB un nodropo external tables. Importēšana, kam seko dzēšana būtu lieka laika tērēšana.

 

Nē. Plānots, ka dati tiek iegūti no vairāk kā 70 ar vienādu struktūru firebird DB un tiek kopā likti vienā db ar vajadzīgajiem laukiem un tabulām nepazaudējot piederību. Tagad to mēģinu darīt iekš mysql ar PDO taisu multiple insert. No sākuma iet raiti ir ok. Bet kā tabulas aug, tā multiple insert paliek lēnāks un lēnāks.... Kādam varbūt ir kāds ieteikums kā to paātrināt. es pāris veidus jau pamēģināju(transaction, konkrētu vajadzīgo lauku daydzums, not null noņēmu, tikai indeksi kur vajag, taisu ne vairāk kā 500 vienā insert, saliku tipus ar nepieciešamo garuma ierobežojumu), bet varbūt ir kas tāds, ko es varu vēl izdarīt? Iekš mysql konfigurācijas?

 

 

Dinamiski pārskati? Statiski?

Būs dinamiski. Principā visas 10 tabulas tiek  sadžoinotas. Un Lielotājam iespēja filtrēt dažādos griezumos.

Labots - piekuns18
Link to comment
Share on other sites

Plānots, ka dati tiek iegūti no vairāk kā 70 ar vienādu struktūru firebird DB un tiek kopā likti vienā db ar vajadzīgajiem laukiem un tabulām nepazaudējot piederību.

 

Šajā gadījumā vismaz es šo problēmu risinātu izmantojot firebird replikācijas. Vai nu pats programmētu, vai ko no šī mēģinātu piemērot

 http://www.firebirdfaq.org/faq249/

Taisītu vienu kopīgu firebird datu bāzi, uz lokālajām atsekotu izmaiņas un replicētu viņas uz centrālo bāzi. Ideja ka pa nakti visu nodzēšam un importējam par jaunu nav pareiza šajā gadījumā.   

 

Principā risinājums elementārs - papildinām vajadzīgās tabulas ar trigeri, kas papildus laukā ieraksta modifikācijas laiku. Vēl papildus lauks DB instances ID. 

Atlasam visus ierakstus, kas modificēti pēc pēdējās replikācijas. Izdzēšam viņus no galvenās db pēc instances + ieraksta ID un pārkopējam jaunos ierakstus no filiāles db uz galveno. Easy ;)

Labots - ronalds_
Link to comment
Share on other sites

piekuns18

 

 

Šajā gadījumā vismaz es šo problēmu risinātu izmantojot firebird replikācijas. Vai nu pats programmētu, vai ko no šī mēģinātu piemērot

dēēmmm. Būs jāpaskatās. nezināju nemaz par ko tādu. Laikam būs te biežāk jāuzdod jautājumi :) Paldies. 


 

 

Principā risinājums elementārs - papildinām vajadzīgās tabulas ar trigeri, kas papildus laukā ieraksta modifikācijas laiku. Vēl papildus lauks DB instances ID.  Atlasam visus ierakstus, kas modificēti pēc pēdējās replikācijas. Izdzēšam viņus no galvenās db pēc instances + ieraksta ID un pārkopējam jaunos ierakstus no filiāles db uz galveno. Easy

 

Nu painteresēšos. Izklausās jau labs risinājums :), bet nezinu vai varu tur kaut ko čakarēt, jo tā nav mana db vai iepriekšēja programmētāja db, bet gan sistēmas db, ko izmantojam par maksu. 

Link to comment
Share on other sites

Bruketajs

 

 

Ideja ka pa nakti visu nodzēšam un importējam par jaunu nav pareiza šajā gadījumā.   

Sevišķi tāpēc, ka tas var kādreiz vienkārši nenotikt, jo.... vienkārši var nenotikt un ko tad?...

+1 par Firebird. Katram ir sava pieredze, bet es ar FB ņemos vēl kopš Interbase laikiem un nav nekas īpašs atgadījies, ja neskaita paša, uz tās bāzes strādājošā, softa brīnumus, bet tas jau ir ieviešanas jautājums. 

Link to comment
Share on other sites

, bet nezinu vai varu tur kaut ko čakarēt

 

Pieliekot papildus lauku un papildus trigeri - tas nekādi neietekmēs esošās sistēmas darbību! Bet bez datiem par ierakstu mainīšanu nekādi replikācija nesanāks. Tā kā datu apjoms ievērojams, tad bez replikācijas nez  vai sanāks visu vienā bāzē atskaitēm salikt. Vienīgais pie sistēmas updeitiem var būt problēmas - var tikt jaunie lauku un trigeri nodzēsti un pazust dati par replikāciju. Tāpēc potenciāli vajadzēs skriptu, kas visu atliek atpakaļ.    

 

Bet parasti normālas sistēmās tiek pierakstīts, kad mainīti dati, piemēram rēķini. Tā kā potenciāli varbūt neko pievienot nevajag. 

Labots - ronalds_
Link to comment
Share on other sites

 

 

No sākuma iet raiti ir ok. Bet kā tabulas aug, tā multiple insert paliek lēnāks un lēnāks.... Kādam varbūt ir kāds ieteikums kā to paātrināt.

 

Inserti paliek lēnāki jo, ja tabulai ir indeksi, tad tie ir jāpārrēķina.

Risinājums, drop indexus, iztira db, piepilda db, create index. 

Link to comment
Share on other sites

Livingston

 

 

Pieliekot papildus lauku un papildus trigeri - tas nekādi neietekmēs esošās sistēmas darbību!

 

Kā papildus lauks var neietekmēt esošās sistēmas darbu?

Ja esošajā sistēmā ir forma vai atskaite, ar "select * from  tabula"  ? 

 

Trigeris arī rada nelielu overhead, bet ar to vieglāk sadzīvot.

Link to comment
Share on other sites

Bruketajs

 

 

Risinājums, drop indexus, iztira db, piepilda db, create index. 

Firebirdam to lieliski paveic bak-rest process, bet jānoliek bāze offlainā...  

Link to comment
Share on other sites

Ja esošajā sistēmā ir forma vai atskaite, ar "select * from  tabula"  ? 

 

 

Ja GUI ir iekš delphi rakstīts - 100% neietekmēs, citās vidēs arī nē, cik zinu! Bet šo takš var elementāri notestēt! 

Cik zinu firebirdam vienīgā vieta kur var būt problēmas ir stored procedūra/trigers, kur ir

SELECT * FROM TABLE1 INTO :VAR1,:VAR2,:VAR3

Te gan neies, bet šāda veida  pieprasījumus rakstīt ir galīgi slikts stils un vismaz es šāda veida pieprasījumus NEKAD neizmantoju!   

 

Ja nu testējot tomēr noskaidrojas ka jaunu lauku nevar, tad taisam papildus tabulu ar diviem laukiem - id un datums.

Un glabājam labošanas laiku papildus tabulā.

Labots - ronalds_
Link to comment
Share on other sites

Livingston

Visu var notestēt, es tikai iesaku nepārsteigties ar secinājumiem, ka elementāra izmaiņa neko neietekmē :)

Link to comment
Share on other sites

Izveido kontu, vai pieraksties esošajā, lai komentētu

Jums ir jābūt šī foruma biedram, lai varētu komentēt tēmas

Izveidot jaunu kontu

Piereģistrējies un izveido jaunu kontu, tas būs viegli!

Reģistrēt jaunu kontu

Pierakstīties

Jums jau ir konts? Pierakstieties tajā šeit!

Pierakstīties tagad!
 Share

×
×
  • Izveidot jaunu...