Delfins

googleit

tu tipa inkludē pēc tam to failu !? Nu pasargāt var: 1. printēt tekstu no faila (file_get_contents()) 2. izņemt ārā <?php (str_replace)

group by text having count(*) = 3

nav vienkāršāk, ka pircējs pats vēlāk atnāk uz veikalu un iesniedz papīrus!? Tik un tā - acis pret aci ir jātiekās - jāliek paraksts.

Ko tu sauc par līzingu!? Kalkulators vai jau gatavs interfeiss uz kaut kādu rēķinu sistēmu ar pēcapmaksu!?

Mani apbrīno šitie koderi... vajag uzkodēt kaut-ko, ko paši nezin ko vajag... A kā tu zini, ka tur vajag tieši otro rindu iekš tā $array[1] !? varbūt no $array[1] tiek sagaidīts, ka tas būs super-objekts

Ir. Izdrukāt kodu uz papīra un palūgt jūzerim atnākt pakaļ tam. Veidi ir N-tie.

TV programmai ir tikai viens pielietojums!.. jeb es kaut ko palaidu garām !?

Takš ir jau, nafig tev vēl vienu saitu !? http://manstv.lv/

EPG ?!

tieši otrādi ... RS ir tā kā tam ir jābūt!

JS Calendar.. pilns google ar free skriptiem.

So what!? kāda starpība?! ... būs tas viss vienā līnijā... ja viņš strādā 8h/dienā tad tie arī ir 8h, nevis kāda daļa tiek sareizināta ar 2x vai 3x. Katra ziņā tas NAV darba laika grafika uzdevums rādīt šādu info (to dara cits grafiks - ražīgums, jeb DarbaUzdevumi/dienā)

Interesanti, kā gan darbiniekam var pārklāties darbalaiki !? Laika dimensija ta viena :) Re kur mans veidojums - dati no velo-pulsometra braukājot pa Rīgu :)

doh... foreach/while (_tavs_masivs_vai_sql) { uzzimet_liniju(darba_laika_dati); // no->lidz }

C'mon... neviens tādus algoritmus neizmanto.. Takš zīmē vesela līnijas... nafig tev ar pikseļiem jāties?

1.) GD - ļoti vienkārši un ērti 2.) DIV - html variants (laiku konvertējam par sekundēm un ar scale_koef iestādam platumu)

Tā saucāmais `aplis` reāli ir tikai tantiņu izdoms... DB tas izkatās kā vairāki maršruti, nevis zem viena rout-a .. tāpēc arī rodas problēmas kaut ko atselektēt. Principā struktūrai vajadzēja būt: Maršruti (templeiti): routes[iD,name] -> rout_points[route_id,point_id] timetable [iD,route_id] -> timetable_points [route_id,timetable_id,point_id,time_in,time_out] Līdz ar to `routes` saturētu konkrētāgadījumā tikai 2 ierakstus: Varoņu->Vipinga un Vipinga->Varoņu Nav svarīgi, ka tas ir viens un tas pats, bet apgriezts. Pēc tāda principa strādā arī rigassatiksme... Laika uzskaitē galapieturā fiksējot laikus un biļešu serijas numurus (laikam).

Heh, taisam lapu Rēzeknes DUS-am!? :) Aplams viedoklis, pabrauc rīgā ar `3` autobusu vai 25. troļuku. Visvienkāršākais veids - reversā selektēšana... to biš tas ir kaut kas līdzīgs grafa apiešanas mehānismam... sāk no beigām (leaf-a) un nonāk citā punktā.. Tā kā šeit ir viendimensijas saturs, tad tas ir vienkārši.. select * from (select * from table where pietura IN (P1,P2) ORDER BY time_in_sec DESC LIMIT 2 ) ORDER BY time_in_sec ASC

Aha... lācim taisnība... bet ir viens BET... IE māk atspiest `nomodificētu` ZIP-u... (proxy serveri pieliek priekšā kaut kādus neizskaidrojamus simbolus - bags vai fīča, ei nu tu sazin) To pašu man rādīja arī http://laacz.lv

Lielai tabulai pie dzēšanas var bremzēt pārindeksācija... Arī esmu ar to saskāries iekš MSSQL. Nedrīkst būt daudz un lieli indeksi.. ir jādomā vnk cits piegājiens. Pareizi jau teica, bez DBA konkrētai RDBMS neiztikt, viņam jābūt klāt kā kreisā roka.

Piedod, bet tādām RDBMS kā ORacle/MSSQL/PgSQL katrs mazs sīkumņš ir ziloņa vērts.. Ir jāredz SQL, ir jāredz izpildes plāns (nevis pie mums, bet pie jums), ir jāizprot, kāpēc ir jātaisa katru reizi COUNT(*) /ar domu visi ieraksti/... Vai tiešām nevar saglabāt to visu kaut kā citādāk? Nokešot to ciparu... vai tml...

pēdējam ierakstam liec kāsīti `Aktīvs` un visas problēmas atkritīs.

uztais statistikas. A vispār nepareizi pajautāts... mēs taču nezinam, vai tu liec kaut kādu klāt WHERE vai ORDER, vai GROUP BY.. vai vispār ir indeksi un t.t.

show/hide .. pilns forums ar piemēriem