litt Posted September 22, 2006 Report Posted September 22, 2006 (edited) Protams, ka zinu.. Bet šajā gadījumā par to negāja runa. Es pieņēmu, ka dzēšot ierakstu ar ID = 3 tika izdzēsti arī saistītie ieraksti un pēc tam "tukšā" vieta aizpildīta ar jaunu ierakstu. Runa gāja par to, ka vienu dienu es pēc SELECT * FROM tabula WHERE id = 3 dabonu vienu (arī atbilstošos saistītos ierakstus, ja paplašinātu kveriju), bet pēc 2 dienām izpildot to pašu kveriju dabūju pavisam citus datus Edited September 22, 2006 by litt
Delfins Posted September 22, 2006 Report Posted September 22, 2006 Nu un ko tas maina? `internal` datiem tas nebūt nav tik svarīgi (kas nav searchos vai kādam uz @ links aizpūsts) Es jau arī nesaku, ka tā ir pareizi. Es tikai pateicu, ka to var izdarīt `manuāli`, nevis automātiski.
Grey_Wolf Posted September 22, 2006 Report Posted September 22, 2006 Delfins --> un dazreiz tas noder :) jo man pasham nesen bija gadijums kur Lielaa DB nejaushi (PHP Admin) tika nodzeests viens ieraksts ... Naacaas izvilkt datus no Backupa un ar rocinjaam vinju atjaunot.... Ja taadas iespeejas nebuutu buutu chaabiski... naktos izdariit izmainjas paareejas tabulaas....
Delfins Posted September 22, 2006 Report Posted September 22, 2006 (edited) PAGA PAGA, Grey_Wolf tavs piemērs ir "līko roku darbs" un šājos gadījumos atbildību nes pats darbinieks/vaininieks, pats no savas kabatas sedz radušos zaudējumus vai vispār kā citādi tiek sodīts... Nopietnās lietās vispār netiek pieļauts "a vot man mysqladmin, a vot es nejauši...". Da izdr*** bez ziepēm/vazelīna! Tāpēc jau programmu/db nav jātaisa, pieļaujot ka tiks pielaistas "šādas līkas rokas". Jātaisa uzreiz normāla DB, ar visiem trigeriem, relations. Pie datiem laiž pašu aplikāciju. un nekādu phpmyadmin... Edited September 22, 2006 by Delfins
Grey_Wolf Posted September 22, 2006 Report Posted September 22, 2006 (edited) tavs piemērs ir "līko roku darbs" un šājos gadījumos atbildību nes pats darbinieks/vaininieks, pats no savas kabatas sedz radušos zaudējumus Aga un ja tas Ir galvenais Boss.... Pat iisti nezinu kaa vinjaam izdevaas to nokilereet...... (preciizaak apmeeram nojaushu) (principaa tieshi vinsh straadaa ar to sisteemu, + Visu tur prograameejis nebiju Es....) un par laimi nebija tur saistito tabulu, bet tajaa pashaa tabulaa saistiiti lauki..... (kurus normaali dzeeshot ierakstu tiek updeitoti) Vienkarshi mineeju kaa piemeeru..... Ka tas dazreiz ir noderiigi..... Edited September 22, 2006 by Grey_Wolf
Delfins Posted September 22, 2006 Report Posted September 22, 2006 Nu ja runā nopietni, tad tavs boss ir lohs: 1.) bosam šādas lietas nav jādara 2.) datus nedrīkst mainīt caur visādiem phpmyadmin (tam paredzēta aplikācija) 3.) nav svarīgi, kas nodropoja ierakstu... vainīgais ir un paliek vainīgais
Grey_Wolf Posted September 22, 2006 Report Posted September 22, 2006 Nu ja runā nopietni, tad tavs boss ir lohs: 1.) bosam šādas lietas nav jādara 2.) datus nedrīkst mainīt caur visādiem phpmyadmin (tam paredzēta aplikācija) 3.) nav svarīgi, kas nodropoja ierakstu... vainīgais ir un paliek vainīgais 1. nush vinsh tur maina datus... taada darba specifika.... (un neko tur mainiit nevar....) 2. Jaqu mineeju iespeejams ka nokreshoja arii caur aplikaaciju, kautgan vinjam ir pieejams arii PhpAmins... 3.. Nu jaa Bet kad atskan breeciens UPS... man taa sanaaca... tad ir jau par veelu..... Fleim OFF... Ne par to ir shii skumjaa teema ;)
v3rb0 Posted September 22, 2006 Report Posted September 22, 2006 :flame on lai cik ar uzmanīgi un pareizi ņemtos ar produkcijas vides db no developera/admina puses, vienalga vienbrīd kko palaid garām un sabeidz (vai nu ar kādu admin tooli, vai paša rakstīto programiņu) db tā ka kkas no backupa jāvelk ārā - tā ir bumba ar laika degli, vienbrīd tas noiks, ja jau noticis, tad notiks atkārtoti. tāpēc db jāaiztiek brīžos kad vismazāk useri to lieto. backupi rulez by default :D :flame off
Recommended Posts