Grey_Wolf Posted October 24, 2007 Report Share Posted October 24, 2007 doti ievades lauki kur ir ipasiba un kautkada vertiba (teiksim 1 vai 2 vai 3) radio buttoni 1 ieraksts: --------------------- IPASIBA | Y | N | Nn -------------------- zils | 1 | | | -------------------- sarkans | | 2 | | --------------------- melns | | 2 | | --------------------- sarkan2 | 1 | | | --------------------- sarkan3 | | | 3 | --------------------- entais | | 2 | | --------------------- 2 ieraksts: --------------------- IPASIBA | Y | N | Nn -------------------- zils | 1 | | | -------------------- sarkans | | 2 | | --------------------- melns | | 2 | | --------------------- sarkan2 | 1 | | | --------------------- sarkan3 | | | 3 | --------------------- entais | | | 3 | --------------------- 3 ieraksts: --------------------- IPASIBA | Y | N | Nn -------------------- zils | 1 | | | -------------------- sarkans | 1 | | | --------------------- melns | | 2 | | --------------------- sarkan2 | 1 | | | --------------------- sarkan3 | | | 3 | --------------------- entais | | 2 | | --------------------- kada Datu tipa lauka butu optimali saglabat datus (vertibas parasti buus 1/2 (Y/N) ar retiem iznjemumiem , bet nevairak par 3 (JA/ Nee/ Nezinu) Meklesanas nosacijumi: piemeram: sarkans N melns N jatgriezj Visi lauki kuros dotie parametri atbilst prasitajam , nenjemot veraa kas daras ar parejiem laukiem (dotajaa piemeraa 1,2 ieraksts) BitVizzas operacijas skjiet ka nederees(pat ja butu tikai Y/N) , jo taas atgrieztu tikai 2 ierakstu... Pasam radaas doma glabat ieksh Stringa un meklesana izmantot masku (dotaja gadijuma #22### saglabajot DB: 1piem. 122132 2.piem 122133 3.piem 112132 ------- Kadi varetu buut risinajumi? shadi lauki buus kaadi 5 vai vairaak un katra no 3 liidz 30 elementiem.... ---------------------- P.S. zinkarigajiem --> Visparastakaas anketas .... Link to comment Share on other sites More sharing options...
Delfins Posted October 24, 2007 Report Share Posted October 24, 2007 Ieraksti Ipasibas Ieraksta_ipasibas (ieraksta_id, ipasibas_id, Y/N/NN) Link to comment Share on other sites More sharing options...
Grey_Wolf Posted October 24, 2007 Author Report Share Posted October 24, 2007 (edited) Delfins --> nee ar starptabulam nav risinajums :( maza piebilde: 1. ipasibas ir jau ieprieksh definetas.... 2. kaa jau mineju taadi lauki buus Vairak ka 5 (pareiz planojas 5) 3. katra buus no 3-30 ipasibas --- dati tiks atlasiti no 3 tabulam , tapec nebuus seviskji pratigi izmantot vel starptabulas... Un vel ieprieks NAV zinams pec cik kriterijiem tiks meklets ... peec 1 vai pilnigi visiem .... taa ka ar starptabulam sanaak analpains PHP pusee.... (var, bet nu pagruti ...) + gribejas izvairiies no N-tajiem AND/OR utt... ----- Ar tam maskam sanak sameraa vienkarshi , bet nevaru saprast par darbiibas atrumu efektivitati.... (cik atri buus LIKE ....) un vai nav vienkarshak (atraak) izmanot N-tos AND.... (smagas aizdomas ka nav gan) edit: tas paraugu tabulinjas ir datu struktura kas tiek savakta no Web.... Edited October 24, 2007 by Grey_Wolf Link to comment Share on other sites More sharing options...
Delfins Posted October 24, 2007 Report Share Posted October 24, 2007 Kas slikts starptabulai !? Ar go gan atšķirās tava maska no OR ? Ja visu saindeksē, tad staptabula rullēs ātrāk, nekā uz katru rindu burtiski REGEXP... kamon. Turklāt jāpatur galvā opciju secību un t.t. Un galu galā,... ierakstam var atšķirties opcijas - būs tāda iespēja uzlikt - tavā gadījumā jāliek vēl viens lauks un atkal jāčakarējās ar stringu. Link to comment Share on other sites More sharing options...
bubu Posted October 24, 2007 Report Share Posted October 24, 2007 Arii neredzu vainu starptabulai. Link to comment Share on other sites More sharing options...
Gints Plivna Posted October 25, 2007 Report Share Posted October 25, 2007 Nu principā jau šādas diskusijas vislabākais tiesnesis ir misters eksperiments ;) Tas noteikti ir daudz labāk nekā dziļi teoretizēt par to, kas varētu būt labāk... Saģenerējam randomā datus vienā formātā, tos pašus pārdzenam otrā formātā (nu vai citus random), bet lai apjoms būtu vienāds un palaižam ciklā kādu baru ar vaicājumiem. Ar vienu diez vai pietiks, jo starpību diez vai varēs novērtēt. Nu un lai izslēgtu visādas pirmās reizes kešošanas un citus vienreizējus nezināmus faktorus šādus vaicājumus palaižam vairākkārt. Fiksējam laiku, paskatamies rezultātus un izdaram secinājumus. Gints Plivna http://datubazes.wordpress.com Link to comment Share on other sites More sharing options...
Delfins Posted October 25, 2007 Report Share Posted October 25, 2007 Ir viens `bet` - vai 10ms ieguvums būs tā vērts, lai mums būtu slikti projektēta DB. To biš laukos glabājās infa, ar kuru visu laiku veido kaut kādas mahinācijas/meklēšanas, ko var vienkārši panākt izmantojot standarta DB fīčas, un turklāt ievērojot normālformas. Tā kā topikā ir: Datu tips tabulas datu saglabasanai lai varetu optimali meklet Tad es domāt, ka nekas labāks par DB indeksiem un parastās meklēšanas (1:1, bez maskām un citām f-ju veidīgajām salīdzināšanām) nevar būt. Link to comment Share on other sites More sharing options...
Gints Plivna Posted October 25, 2007 Report Share Posted October 25, 2007 Ir viens `bet` - vai 10ms ieguvums būs tā vērts, lai mums būtu slikti projektēta DB. To biš laukos glabājās infa, ar kuru visu laiku veido kaut kādas mahinācijas/meklēšanas, ko var vienkārši panākt izmantojot standarta DB fīčas, un turklāt ievērojot normālformas. Jā šis protams ir vērā ņemams arguments, bet kā jau teicu 1) jāpārliecinās kas strādā ātrāk un par cik 2) esmu gatavs pieņemt, ka atsevišķos gadījumos pilnībā apzinoties sekas :) ir iespējams attālināties no visādiem likumiem, jo likumi jau tāpēc ir, lai tiem būtu izņēmumi :) BET kā jau teicu ir jāapzinās sekas, un jāsaprot kādas prasības šeit būs un kādas nebūs, un kā mēs tās varam realizēt gadījumā A un gadījumā B. Tā kā topikā ir: Tad es domāt, ka nekas labāks par DB indeksiem un parastās meklēšanas (1:1, bez maskām un citām f-ju veidīgajām salīdzināšanām) nevar būt. Nu principā indeksi strādā tad, ja ir jāatlasa relatīvi maz datu no tabulas. Šeit faktiski nav īsti skaidrs cik daudz datu no tabulas tipiskā gadījumā būs jāatlasa un varbūt var gadīties, ka full skans būs izdevīgāks. Bet atkal šī ir teoretizēšana, es priekšroku dotu praktiskam eksperimentam. Pie tam ja šādi vaicājumi būs ļoti bieži var sanākt, ka neviena no šīm struktūrām nestrādās pietiekami ātri. Iespējams ir vērts padomāt par kaut ķadu atvasinātu struktūru, kurā ir saskaitītas visas atbildes griezumos pa visiem jautājumiem vai tml. Tas viss protams ir atkarīgs no biznesa prasībām, iespējams, ka potenciālās vēlmes ir tik dinamiskas/neprognozējamas vai arī vaicājumi notiek relatīvi reti un nekādas atvasinātas struktūras neatmaksājas uzturēt. Gints Plivna http://datubazes.wordpress.com Link to comment Share on other sites More sharing options...
Recommended Posts