Autor Zpráva
H13
Profil
Ahoj, který zápis pro uchování hodnoty je podle vás optimální:

a) vzhledem k využití paměti
b) vzhledem k přehlednosti zápisu


1)
$pole = array();
$pole[] = 'nejaka hodnota 1';
$pole[] = 'nejaka hodnota 2';
$pole[] = 'najaka hodnota 3';

2)
$pole = array();
$pole[0] = 'nejaka hodnota 1';
$pole[1] = 'nejaka hodnota 2';
$pole[2] = 'najaka hodnota 3';

3)
$pole = array();
$pole['hodnota1'] = 'nejaka hodnota 1';
$pole['hodnota2'] = 'nejaka hodnota 2';
$pole['hodnota3'] = 'najaka hodnota 3';

4)
$object = new Object();
$object->hodnota1 = 'nejaka hodnota 1';
$object->hodnota2 = 'nejaka hodnota 2';
$object->hodnota3 = 'najaka hodnota 3';

díky Honza
Majkl578
Profil
1 a 2 jsou totozne

pokud bych to resil objektove tak 4, jinak asi 3ku, ale zalezi na situaci. pamet by me u tech poli moc netizila, jedna se beztak jen o par bajtu
Mastodont
Profil
Vytvářet objekt jen jako úložiště hodnot? To neberu. A u polí záleží na tom, jestli chci ukládat dvojici klíč-hodnota nebo jen hodnoty - ve druhém případě je varianta 3 zbytečná.
AM_
Profil
mezi 1 a 2 rozhodně jedna, pak se v kódu rozhodneš první z padesáti hodnot odstranit a budeš přepisovat indexy zbylých 49ti?
Objektová verze je příšernost.
H13
Profil
no ptám se proto, protože jde o např. 100 hodnot, takže bych rád použil 1) nebo 2) jenže se potřebuju v kódu vyznat, takže čísla asi nepoužiju :-(

zbývá tedy
3) a 4)

o 3) jsem slyšel, že si php pro sebe vytváří nové pole, kde textové klíče nahrazuje číselnými, což by znamenalo větší náročnost, takže nevím jestli nemám rovnou použít objekty (když mám skoro vše v objektech)

celkem by mě zajímalo rozdíl mezi 3) a 4) např. v náročnosti na paměť
Mastodont
Profil
php pro sebe vytváří nové pole, kde textové klíče nahrazuje číselnými
Pokud vím, tak je to přesně naopak - klíče jsou interně vždy asociativní.
http://oreilly.com/catalog/progphp/chapter/ch05.html

rozdíl mezi 3) a 4) např. v náročnosti na paměť
http://particletree.com/notebook/object-oriented-php-memory-concerns/
H13
Profil
Mastodont
Aha, takže jsem to popletl:

PHP internally stores all arrays as associative arrays
znamená to tedy, že si php rychleji a optimálně poradí s polem, které má asociativní klíč než s polem číselným (protože pro něj interně stejně bude vytvářet asociativní klíč) ?
Mastodont
Profil
H13
To nevím, znamenalo by to studium zdrojáků .... ty jsou ale volně k dispozici, takže se můžeš začíst :-)
H13
Profil
Mastodont
:-) no i když mi je céčko sympatický, tipuju že tohle asi prozkoumat nedokážu :-(
bohyn
Profil
PHP internally stores all arrays as associative arrays
znamená to tedy, že si php rychleji a optimálně poradí s polem, které má asociativní klíč než s polem číselným (protože pro něj interně stejně bude vytvářet asociativní klíč) ?

Nakonec pole stejne skonci jako ciselne (C/C++ asociativni pole nezna) nebo jako objektovy kontejner. Co je rychlejsi bych v tomto pripade moc neresil, rychle je oboje. Pouzij to co lepe odpovida logice pouziti, pokud mas soubor nacteny do pole tak k nemu asi tezko budes pritupovat $soubor['radka156'], ale $soubor[156]. Kdyz to bude treba konfigurace tak je prehlednejsi asociativni pole napr.: $config['debug']
AM_
Profil
Asociativní pole určitě rychlejší nebude, pokud jsi to pochopil tak, že $pole[1] se interně reindexuje na $pole['one'], tak to asi ne :)
Primárně se drž přehlednosti a logiky; popsal si 3 způsoby, který se každý používá k něčemu jinému, a neřekl jsi, k čemu. Tak jak ti máme poradit, který je lepší? To, že tam budeš mít stovky prvků, zase vylučuje objektové řešení dle tvého návrhu - představ si definici třídy:
class myClass{
  public $jedna;
  public $dva;
  public $tri;
  public $ctyri;
  public $pet;
//... 100x
}
Mike8748
Profil
AM_
To, že tam budeš mít stovky prvků, zase vylučuje objektové řešení dle tvého návrhu
omyl

takova definice vubec neni treba. od toho je treba trida stdClass. a co SPL a implementace ArrayAccess ? moznosti jak definovat tridu aniz by si musel definovat vsechny jeji promenny, je vice nez dost

... ale... objektovy zapis je vhodny akorat pro "krasu" zapisu, pripadne moznost pristupu jako k objektu. ve vysledku to stejne PHP udrzuje jako pole.
AM_
Profil
ok, ale stejně to na výsledku nic nemění, že pro prostou množinu proměnných se třída nepoužívá.
Aesir
Profil
H13:
Bylo by ideální říct i k čemu to slouží, jestli jsou nad tím polem potřeba i nějaké operace, bude to příjemnější mít v objektu.
Jinak co se týče optimalizace, tak na to má smysl koukat až u hotové aplikace.
H13
Profil
No všeobecně hledám způsob zápisu, není to konkrétně...

Příklad (pouze ilustrativní):
Tabulka v databázi obsahuje data: id, jmeno, prijmeni, popis.
Vytáhnu informace z databáze a dostanu je do objektu (pokud je více řádků, do pole s objekty)

Takže dostanu:

$object->id
$object->jmeno
$object->prijmeni
$object->popis

Během skriptu pak různě upravuji a přidávám hodnoty, např:

Úprava:
$object->popis = $object->popis . "a jeste nejaka pridana hodnota";

Přidání:
$object->dopis = "Vážený pane " . $object->jmeno . " " . $object->prijmeni " .... "
$object->adresa = (např. nějaký načtení z nějaký další tabulky)
$object->objednavka = ...

Prostě není to tak, že bych ve třídě definoval všechny prvky (jak píše AM_), ale během skriptu podle podmínek prostě přidávám a měním hodnoty a prvků může být např. na začátku 10 - 20 a na konci třeba až 100. Ty rozšířené se pak mohou použít na výstup, ty základní pak např. změnu dat v databázi...

Takže jde třeba o to, že základní prvky mám stejně v objektech, zda mám pokračovat v objektech nebo např. využít místo:

$object->dopis

$objectPole['dopis'];

Jestli má cenu kvůli optimalizaci takto jakoby znepřehledňovat kód dvojitým zápisem...
Aesir
Profil
H13:
Pokud přemýšlíte nad něčím takovým, tak je možná na čase si přečíst něco o návrhových vzorech active record, data mapper, row|table data gateway, apod.
H13
Profil
no dá se říct, že by to platilo pro položky databáze, což např. využívám

z databáze se dostanu k objektu

např. $object->id

a $object->id se např. při změně převede do databáze...

Pokud např. vkládám nový prvek, nejdříve se vytvoří prázdný objekt:

$object->id = null;
$object->name = null; (dá se říct, že se jakoby inicializuje)

provede se zadání nových hodnot, např.:
$object->id = 1;
$object->name = "Jméno";

a to se zpět vloží do databáze...

Co ale s položkami, které nejsou spojeny s databází:
- nechat v objektech, aby byl používán jednotný styl?
- dávat do polí, kvůli optimalizaci?

Když se např. dívám na stránku s testy, kterou sem vložil Mastodont, pak bych spíše volil pro ostatní položky pole (míchání pole a objektu, ale většinou by objekt reprezentoval pár sloupců v databázi např. 10, zatímco pole by obsahovaly dalších např. 120 položek)
Aesir
Profil
H13:
Co ale s položkami, které nejsou spojeny s databází:
- nechat v objektech, aby byl používán jednotný styl?
- dávat do polí, kvůli optimalizaci?

To ale záleží na tom, co je to za objekt. Pokud je to objekt např. "osoba", tak relevantní parametry (jméno, příjmení, věk,...) mějte klidně v nějaké jeho instanci, i když jsou potřeba jen pro jeden request (není potřeba je ukládat do db). Nerelevantní parametry (např. barva sousedovic auta) tam nemají co dělat.

Takže opravdu záleží na konkrétním použití, aby se dalo říct co je zrovna v tomto případě výhodnější nebo "správnější". Pokud to má být jen úložiště nesouvisejících dat, tak do pole s tím, ale i to se dá samozřejmě udělat "objektově" - dá se extendnout SPL ArrayObject, udělat si jeho unikátní statickou instanci a máte hotové globální úložiště čehokoliv s výhodami přístupu jak k objektu, tak k poli.
H13
Profil
Tady si asi nerozumíme, já jsem se neptal, jaký položky mám ukládat do databáze, ale pokud položky neukládám do databáze, zda je vést ve skriptu jako pole nebo objekt...

Zda např. upřednostnit přehlednost a dát všechny položky do objektů, což může být výhodou např. při procházení foreachem, nebo dát položky, které se do databáze neukládají a vznikají a zanikají během skriptu do polí, což zase ušetří paměť a čas)

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: