Jump to content
php.lv forumi

Gudra db klase


codez

Recommended Posts

Ideja aptuveni tāda:

 

$user=DB::get('users','id=1');

 

$user, tagad ir kaut kas līdzīgs active record.

 

echo $user->id;
$user->info='user info';
$user->save();

 

Piemēram, users mysql tabula var saturēt desmitiem laukus, bet iepriekšējā piemērā tiek izmatoti tikai 2 lauki: id un info, bet lasot attiecīgo row-u, db klase nevar zināt, kurus laukus tālāk kodā izmantos, tāpēc ir jāselekto visi.

Tātad ideja ir tāda, ka klase katra konrkētā active record-am izsaukšanu kaut kā atcerās, piem., pēc rindas nr, pēc izsaukuma parametriem, utt., un tad koda darbības laikā piefiksē visus izmantotos laukus un attiecīgi nākamreiz selekto tikai tos laukus. Ja kāda koda atzara (if-a) gadījumā tiek izmantots jauns lauks, tad tajā vietā pārselekto row-u un atzīmē, ka šim active record-am var tikt izmantots arī šāds lauks.

 

Vai kāds ar kaut ko līdzīgi ir sastapies vai arī ir kādas labākas idejas, kā risināt šādu optimizācijas problēmu?

Link to comment
Share on other sites

Nekas šajā gadījumā nebūs ātrāks par opcionālu trešo parametru get metodei, kurā tad tu norādi ko tieši tev vajag (by default ķer visu). Mīnuss. Kods nebūs tik fleksabls. Ja vajadzēs lietot jaunu parametru, tad to vajadzēs pievienot get izsaukumā.

 

Domāju, ka tāda gudrā "atcerēšanās" rīs tik pat daudz resursus kā visu lauku selektošana, jo tas viss tā pat būs kaut kur jāpieglabā un jāatrod visas references failiem un rindām. + kas notiks, ja mainīsies rindas nr? (pievienojas jauns kods). Kas notiks ar novecojušo info? (ok var laist kaut kādu garbage collection, kas ik pa laikam attīra visu, lai viss kešojas no jauna).

 

Vai prātīgāk nebūtu tērēt laiku domājot par tādiem risinājumiem kā memcached un/vai Redis DB, ja ir plānoti daudz izsaukumi.

Link to comment
Share on other sites

memcached var būt kā layer-is active record-am, bet tas neatceļ šo optimizācijas iespēju arī memcached izmantošanas gadījumā.

Parametrus likt manuāli nešķiet laba doma, jo tas pieļauj iespēju pielaist kļūdu parametru neieliekot vai ieliekot liekus parametrus.

 

Tikko radās ideja, ka klase varētu pati modificēt kodu., piemēram pēc šāda koda palaišanas:

 

$user=db::get('users','id=1');
$user->info='abc';
$user->info2='abc2';
$user->save();

 

kods pārvērstos par

 

$user=db::get('users','id=1','info,info2');
$user->info='abc';
$user->info2='abc2';
$user->save();

 

 

Mana galvenā ideja ir radīt aplikāciju izstrādes framework-u, kurš būtu viegli lietojams un universāls, bet tai pašā laikā nezaudējot ātrdarbību. Respektīvi tādu nedaudz intelektuālu framework-u

Link to comment
Share on other sites

Iespējams, tas, protams, būtu bet tas prasītu krietnu pūliņu devu. Īpaši zarošanās gadījumos, jo vienu reizi tiks prasīta viena lieta, citu reizi cita. Tātad kaut kur tik un tā būtu jāpieglabā kas kuros gadījumos notiek.

 

Vēl viena problēma ir koda pārģenerācija. Tas IMO, nedaudz, apgrūtinātu debugošanu paša koda rakstīšanas brīdī. Vismaz ja es pareizi iedomājos kā varētu veikt koda pārģenerāciju un kuros brīžos.

 

 

Intelektuāls un ātrs freimvorks ir laba lieta, bet visur, diemžēl, ir robežas (vismaz saprāta :D).

Link to comment
Share on other sites

Pats pašlaik spēlējos ar miniatūru ORM.

 

Apskaties funkciju get_object_vars. Tas tev varētu dot kādu ideju.

Un workaround'u priekš late static binding uz PHP < 5.3.0 tu atradīsi tepat forumā.

 

 

Reku tev pārdomām šitāds koda fragments:

class Book extends Table{
var $title;
var $author;
var $year;
}

$collection = Book::find( array('where' => 'year > 2005', 
			'limit' => 10 ));
foreach ( $collection as $book ){
echo $book->title; 
}

$flawed = Book::find( 3 );
$flawed->author = "Jim Butcher";
$flawed->save();

Link to comment
Share on other sites

īzmantojot statiskās funkcijas, kā jūs glabājat sql konekcijas handleri? kā globālu mainīgo/MVC reģistri?

 

esmu arī domājis par kaut kādas universālas klases ieviešanu, bet vairāk saistīts ar vairāku db suportu (mysql, postgre, sqlite), manu uzdevumu apgrūtina tas, ka katrai db ir savas funkcijas, savas mainīgo interpretācijas, sql pieraksts galu galā. mūsdienās jau reti kurš ar standarta sql var iztikt.

Link to comment
Share on other sites

īzmantojot statiskās funkcijas, kā jūs glabājat sql konekcijas handleri?

 

Kā statisku klases mainīgo.

Ideja aptuveni sekojoša:

 

db instance glabājas klases statiskā mainīgajā $instance.

statiskā funkcija i() skatās, ja instance nav izveidota, izveido to un atgriež db klases instanci.

Tālāk jau visās pārējajās statiskajās funkcijās pēc klases instances griežas caur self::i().

 

<?php
define('DB_HOST','localhost');
define('DB_LOGIN','root');
define('DB_PASS','');
define('DB_DB','test');

class db{
 private static $instance;
 public static function i()	{
   if (!self::$instance instanceof mysqli){ 
     self::$instance = new mysqli(DB_HOST,DB_LOGIN,DB_PASS, DB_DB);
     self::$instance->set_charset("utf8");	
     self::$instance->autocommit(false);      			
   }
   return self::$instance;
 } 
 function q($q){
   return self::i()->query($q);
 }
}

$res=db::q('SELECT * FROM a LIMIT 1');
print_r($res->fetch_assoc());
echo '<br />';
var_dump(db::i());
echo '<br />';

Link to comment
Share on other sites

Neko tādu neesmu redzējis. Parasti ir tādi kā table view(vai nu view, query, business view... kā kur nosaukti) un tie view satur lauku sarakstus, indeksus, vai nu pat query ar joiniem. Tad tos piesaista programmai, formai, atskaitei un tt. Iekš MVC tās laikam skaitās model. Nu bet vienalga ar rokām definē laukus un tas nemaz neaizņem daudz laika.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...