cilveks

SELECT id FROM tab1 EXCEPT SELECT id FROM tab2;

Pēc andrisp teiktā uzreiz nāk prātā šis:

One of the most significant problems in software development is assuming. If you assume a method will passed the right parameter value, the method will fail.

– Paul M. Duvall

SELECT COUNT(ielaze) FROM ielazes

Salīdzina ne tikai vērtību, bet arī tipu.

http://lv.php.net/manual/en/language.opera....comparison.php

Ja pareizi sapratu tavu domu.

SELECT name, surname FROM users WHERE nick LIKE 'ozols'

http://www.postgresql.org/docs/8.2/interac...s-matching.html

bubu, ne velti izcēlu vārdu "tavuprāt".

Drīkst zināt ko, tavuprāt, tev dos overklokings?

Un pie otrā punkta papildinājums: ar nosacijumu, ja korekti uzstādīsi bootloaderi.

SELECT * FROM serveri WHERE rownum <=100;

....

echo "<img src="koolbaner.jpg">"

echo "<h2>Sveicināti!</h2>Šī ir īsa ziņa!"

Šeit latviski aprakstīts

http://datubazes.wordpress.com/2007/12/03/datubaze/

Vispār jau pēc lasītā (vairākos avotos lasīts), iepriekšminētā ķiniešu profesore Xiaoyun Wang kolīziju atrada ar "rokām". Un viņa ir 5 dažādas hešfunkcijas "uzlauzusi".

In Crypto’04, Wang announced some collision examples on a series of hash functions.

1 MD5: Finding a collision with probability 2^37 (2004).

2 MD4: Finding a collision with probability 2^2-2^6.

3 RIPEME: Finding a collision with probability of 2^19.

4 HAVEL-128: Finding a collision with probability of 2^7.

Ja tu šos teikumus pārveidosi sakarīgā teikumā, latviešu valodā (galvenais lai domu varētu saprast, lai nebūtu divdomību):

Kads varetu pateikt kodu vina kvadrati tjipa ir body backgrounds un ieksejais

Kas traume kads nezina ka ?

Es saprotu et neieveroju likumus utt pasakat kodu un viss!!

es gibu taka te ta ka vins kvadrats ir otra

Mans jauajums ir kas jaaksta

Nevajag jau pilnīgi perfekti, saprotu, katram gadās kļūdīties.

Un šos vārdus pārveidosi latviski:

kr4

vaig

nevart

omfg

4ateris

veba

tnq

nejiet

akaet

js

unn

et

Un pateiksi savu domu tādā teikumā, ar pieturzīmēm tik daudz - lai tevi varētu saprast.

Tad es vai kāds cits tev iedos precīzu atbildi.

Jā, ņem vēl vērā ka noteikti vajadzēs supportu, kopā sanāks 6 ciparu skaitlis.

<?php

echo "Server monitor";

?>

Nokia 3310, un neko vairāk neprasās mobilajam.

Sveiks!

Varbūt vari iemest šeit problēmas aprakstu? Varbūt kādam ir jau līdzīgs skripts, un attiecīgi varēs tev dot norādes. Vai arī kādam nebūs ko darīt un uzrakstīs(vismaz daļēji):). Neesam mēs, programmētāji, tik "skopa" tauta (atskaitot dažus atsevišķus indivīdus:). Kā arī kā saki, tas nemaz nav pusstundas darbs.

Var kaut vai šādi:

SELECT attalums FROM attalumu_tabula WHERE city1_id = 12 AND city2_id = 17

andrisp: nē tas nebija cascade delete, tur bija nedaudz citādāka doma.

PostgreSQL tiek aktīvi lietots, bet vienkārši ir liels projekts kur izmantots orāklis. Un ir pāris labojumi šim projektam jāveic, neba viss no nulles jāuztaisa. Un es jūtu ka orākļa zināšanas man var noderēt arī nākotnē, kas ir ļoti liels pluss tam, un uz priekšu ar iet, nav tā ka esmu galīgi iestrēdzis kaut kur orāklī.

Delfins ne tur tā problēma. Problēma ka dzēšot ierakstus no šis tabulas, šis process aizņēma laiku. Tad saku meklēt cēloni un uzgāju to ka ne tikai dzēšana bremzē. Ka ir arī pāris citas "lietas" attiecibā uz šo DB, kas iebremzē šajā projektā. Kur varēšu, izmantošu kešošanu. Ir šajā projektā jau izmantota kešošana, bet acīmredzot vajag vēl dažās vietās.

Šobrīd nav skaidrs ko darīt ar dzēšanu :/ Dažreiz dzēšot izmet kļūdu, integrity constraint.

DELETE FROM liela_tabule WHERE kautka_id = xx

Sheit viņš var izdzēst pat 3000 ierakstus. Datubāzes ir mana vājā puse. Bet padoties ar netaisos, mācos. Būs jāizlasa kāda nopietna grāmata par orākli, nevis sagrābstīt ziņas no forumiem && googles. No googles esmu dzirdējis par tādiem dzēšanas paņēmieniem kur visa dzēšana tiek "apvienota" kā viena lielā dzēšana, ja nemaldos šķiet tas vārds bija autonomā dzēšana, bet baidos kļūdīties. Sīkāk nemācēšu pastāstīt, ar' tikai no googles dzirdēts.

Roze: mans mērķis nav(nebija) uzzināt cik ilgi izpildās. Tikai dotajā bridī interesēja vai tiešām būs būtiskas atšķirības starp count(id) un count(*), būtiskas nebija. Par autotrace, nemaz nezināju(nezinu) ka var ko sīkāk uzzināt par vienu kveriju. Oriģinālais kverijs ir garāks, es vienkārši viņu centos maksimāli novienkāršot, lai izslēgtu nebremzējošos faktorus.

Paldies par norādi uz autotrace. Pameklēšu sīkāku info.

Tabula ir indeksēta. Es mēģinu dažādus nosacījumus, gan bez, gan ar WHERE, gan dzēšot ierakstu - rezultāts tāds pats.

andrisp nedomāju ka count(*) ir ātrāks, jo, manuprāt, tas ietver sevī visus laukus un līdz ar to teorētiski tam vajadzētu ilgāk laika paņemt. Testa pēc pamēģināju un uz aci mērot šķita ka ir ilgāk. Bet to tā objektīvi nevar noteikt, jo tā datubāze nepārtraukti tiek lietota, respektīvi noslogota.

Grey_Wolf: es īsti neticu ka tā ir. Un ar' cik orāklis var būt haļavnijs? Cik es zinu viņam "haļavnijām" versijām ir tikai noteiktas prasības pret dzelžiem (kādi max dzelži var būt).

Vai arī otrs variants, tas ka datubāze nepārtraukti tiek lietota, tas arī ir tas bremzējošais faktors. Jo kā nekā vienlaikus tik daudz pieprasījumi. Tādā gadījumā tur noteikti kaut kas nav uztaisīts tā lai optimāli strādātu, bet nu to es neizmainīšu.

Bet ko darīt ja tabulā garumzīmes/mīkstinājumzīmes saglabājās kā piem <C2> utml. Viss strādā normāli, lapā ar korekti izvada, bet ORDER BY atgriež nekorektus rezultātus.

Ir pieejama viena tabula(orāklī) kur ir 90 miljoni ieraksti. Un vaicājums SELECT count(id) FROM tabula aizņem vismaz pāris minūtes, vai tas ir normāli šāda apjoma tabulai?

edit: pārpratu