Witam,

Co będzie działało szybciej w praktyce: pobranie dwóch pól z tabeli np. typ, np. "strona" oraz id, np. "1" i ich pobranie czy może jedno pole, np. strona/1, a następnie rozdzielenie w PHP (np. funkcją split)? Co będzie szybsze? Tylko nie piszcie "Zrób testy to się dowiesz". Może ktoś już miał podobny problem i robił testy lub ma większe doświadczenie. Myślę, że przy większej bazie, np. z milionem rekordów może to mieć duże znaczenie.

Pozdrawiam

A właśnie napiszę - przyda Ci się microtime" title="Zobacz w manualu PHP" target="_manual


Owszem - poszukiwanie wg tych pól i rozbrajanie ich w SELECT byłoby bezsensem...

Robienie testów jest trochę pracochłonne ale może się opłacić w ostatecznym rozrachunku:) Myślałem właśnie o użyciu microtime.

- nie za bardzo rozumiem co miałeś tutaj na myśli, tzn. że bez robienia testów jesteś za splitem?

bez pracy nie ma kołaczy


Nie - jestem za umieszczeniem danych w osobnych kolumnach. Przy splicie wyciąganie danych przez zapytanie byłoby bardziej zasobożerne.

@phpowiec2: czy Tobie przypadkiem nie chodzi o coś takiego

[SQL] pobierz, plaintext 
SELECT (`id`, `strona`) FROM `typ` WHERE (...)
[SQL] pobierz, plaintext 

?

bardziej o coś takiego

SELECT (`id`, `typ`) FROM `tabela` WHERE (...)

lub druga opcja

SELECT (`id_typ`) FROM `tabela` WHERE (...)

i pobraną wartość (w formie np. "strona-1") dzieliłbym sobie na zmienne poprzez split

A po grzyba to dzielic w php, skoro mozesz miec pobrane w osobnych polach?
I po grzyba trzymac polaczone w bazie -co z tego bedziesz mial?
Jak bedziesz chcial jakies zlaczenie, warunek w bazie zrobic na tych polach to ja zajedziesz.
A pobranie ich osobno i tak jest szybkie, a tylko sobie komplikujesz niepotrzebnie system.


No raczej nikt nie wpadl na tak glupi pomysl.

Po takiego grzyba, że zapytania do bazy optymalizuje się m. in. w ten sposób, że pobiera się jak najmniejszą liczbę pól przy zapytaniu. Przy malutkiej bazie i małej ilości zapytań oczywiście nie ma sensu się bawić w takie rzeczy. Sytuacja komplikuje się przy dużej bazie i ogromnej ilości zapytań.



Przecież można trzymać dane też w polach osobno (na wypadek skorzystania), tylko z nich nie korzystać w aplikacji, wiadomo.

Że tak powiem, w jednej kolumnie trzymam jedne dane. Jak miałbym później rozdzielać w php, to już bym wolał sobie to w pliku trzymać, bo po co wtedy baza?

to zrob ten test a oswiecisz nas wszystkich. Zajmie ci to 10 minut wlacznie z wlozeniem miliona rekordow do bazy (choc proces generowania miliona rekordow moze potrwac dluzej niz 10 minut)

Ja osobiscie jestem za dwoma polami. zdecydowanie latwiej wowczas przeprowadza sie wszelkie operacje na bazie - uwierz na slowo.

Podobne rozwiązanie widziałem w Drupalu i stąd moje dywagacje na ten temat.

A czy tam nie jest przypadkiem coś w stylu cache'u mapowań rewrite zapisanych w celu szybszego odczytu?

też ale nie tylko

Pobiera sie taka liczbe pol jaka potem potrzebujesz.
Nigdzie tu nie mowia zebys "trzymal caly rekord w jednym polu".
I wez te testy przeprowadz, 4h tylko gadasz zamiast to dawno zrobic.

wyobraź sobie, że chcesz wyszukać rekord typ:strona o id=15, ciekawe ile to by zajęło czasu... (i napisanie jeszcze dobrego zapytania, które to wszystko rozdzieli i porówna) :/

A ja dodam tylko że powinno być w osobnych polach. Bo jak wyniki z teorii baz danych błędne są tabele które w polach zawierają dane wielowartościowe.

Zrób w osobnych kolumnach...

Bo ostatecznie okaże się że ze splitem nie jest wcale wydajniej (bolączką bazy jest wyszukiwanie a nie pobieranie)...

A jak będzie wydajniej to róznica będzie taka że musiałbys mieć aplikację z milionami requestów żeby miało to jakies znaczenie....