Forum PHP.pl

Zakładając że wiadomość nieprzeczytana to taka, która ma datę dodania większą (późniejszą) niż ostatnia data oglądania konwersacji przez danego użytkownika i znajduje się w tej konwersacji to można:

[SQL] pobierz, plaintext 
SELECT count(*) AS nieprzeczytane
FROM konwersacje_czlonkowie kc JOIN konwersacje_wiadomosci kw 
ON kc.konwersacja_id = kw.konwersacja_id
AND kc.konwersacja_ostatnio_ogladana < kw.data_wyslania
WHERE kc.uzytkownik_id = ?
[SQL] pobierz, plaintext 

Pole wiadomosc_ogladana w tabeli konwersacje_wiadomosci jest do usunięcia, nie ma tam sensu.
Nie sprawdzasz też nigdzie czy konwersacja została usunięta, ale to już musisz sam przemyśleć jak to zrobić, bo być może to pole powinno być w tabeli konwersacje albo też użytkownik może chcieć się wypisać z danej konwersacji i tylko dla niego jest ona niewidoczna (usunięta) podczas gdy inni mogą dalej w niej pisać i wtedy to pole jest w dobrym miejscu, choć dziwnie nazwane.

Pomijając zasadność takiej struktury danych, jeśli tak ma być to wystarczy jedno zapytanie

[SQL] pobierz, plaintext 
SELECT o.nazwa_obiektu, a.nazwa_atrybutu, a.nr_kolumny, w.nazwa_wartosci 
FROM pozycja p
JOIN atrybut a ON p.atrybut_id_atrybutu = a.id_atrybutu
JOIN obiekt o ON p.obiekt_id_obiektu = o.id_obiektu
JOIN wartosc w ON p.wartosc_id_wartosci = w.id_wartosci
WHERE a.tabela_id_tabeli = 1 AND o.tabela_id_tabeli = 1
ORDER BY o.nazwa_obiektu, a.nr_kolumny
[SQL] pobierz, plaintext 

I do zbudowania tabelki w html to jest wszystko co trzeba. Można sobie całość zapisać w tablicy lub też tylko pierwszy wiersz żeby zrobić th a potem po kolei sprawdzamy rekordy i jeśli zmienia się nazwa obiektu to zamykamy tr, otwieramy nowe i wstawiamy na początek dodatkowe td z nazwą obiektu a oprócz tego dla każdego rekordu dodajemy td z nazwą wartości.

Trudno określić co w tych tabelach siedzi, zazwyczaj podanie struktury tabel to pierwsze co robią ludzie szukający pomocy. Zwłaszcza jeśli wyniki ze screena z phpmyadmina wyglądają podejrzanie jeśli chodzi o wartosc_num. Może to miały być numeryczne odpowiedniki słów TAK NIE WYSOKA itp? W ogóle to zapytanie wygląda dziwnie, choć bez struktury ciężko powiedzieć.

Ogólnie do wyświetlania takich tabelek należałoby dodać sortowanie w zapytaniu typu ORDER BY wiersz,kolumna czyli przykładowo ORDER BY nazwa_obiektu, nr_kolumny po czym ciągnąc z bazy poszczególne rekordy przy zmianie nazwy obiektu wstawiamy htmlowy koniec i początek nowego wiersza tabelki. Ewentualnie znając konkretne ilości można dwie pętle jedna w drugiej zrobić. Ale to pod warunkiem absolutnej pewności że jest dokładnie tyle ile trzeba w bazie.

Do wyciągania ilości rekordów lepiej używać zapytań typu "SELECT COUNT(*) FROM obiekt" niż brać wszystko z tabeli i odczytywać num_rows.

Jeśli się uczysz to staraj się unikać funkcji mysql_ , które są mocno przestarzałe i od razu ucz się przynajmniej mysqli_ , nawet jeśli obiektowe podejście wydaje się na początku niezrozumiałe. Do znalezienia w sieci jest masę poradników z gotowymi kawałkami kodu do podstawowych operacji na bazie.

[PHP] pobierz, plaintext 
$links = array ( "https://pl.wikipedia.org/wiki/xkhksa",
                 "https://pl.wikipedia.org/wiki/fdgdf",
                 "https://pl.wikipedia.org/wiki/trtert",
                 "https://en.wikipedia.org/wiki/fdgdf" );
 
$grlinks = array();
 
foreach( $links as $key => $url )
    $grlinks[substr($url,0,strpos($url,'/',9))]=$url;
 
$grlinks=array_values($grlinks);
 
print_r($grlinks);
[PHP] pobierz, plaintext 

Dla każdej tabeli:

[SQL] pobierz, plaintext 
UPDATE `nazwatabeli` SET `data`=DATE(`time`);
[SQL] pobierz, plaintext 

oraz

[SQL] pobierz, plaintext 
ALTER TABLE `nazwatabeli` ADD INDEX `d_v`(`data`,`value`);
[SQL] pobierz, plaintext 

W zapytaniach o najwyższą(najniższą) wartość dzisiaj:

[SQL] pobierz, plaintext 
... WHERE `data`=CURDATE() ORDER BY `value` DESC LIMIT 1
[SQL] pobierz, plaintext 

Z tego co autor napisał wynika, że tabele są dla różnych czujników, a każda ma dane od początku, więc WHERE jest niezbędny by mieć dane z konkretnego dnia.
Co do optymalizacji pierwszym problemem jest tutaj fakt, że w tym warunku WHERE wykonujemy funkcję na kolumnie, co nie kwalifikuje indeksu na tej kolumnie do wykorzystania. Można próbować przepisać to w ogólnej postaci jako na przykład

[SQL] pobierz, plaintext 
 ... WHERE `time` BETWEEN '2016-08-01 00:00:00' AND '2016-08-01 23:59:59'
[SQL] pobierz, plaintext 

albo prościej dla dzisiejszego dnia o ile nie ma możliwości by były jakieś późniejsze wpisy:

[SQL] pobierz, plaintext 
 ... WHERE `time` > CURDATE()
[SQL] pobierz, plaintext 

jednak w najlepszym przypadku dostaniemy w explain type=range, a do tego nie da się potem podczepić następnej części indeksu do sortowania wartości. W zależności od ilości danych może to być szybsze niż pełen skan tabeli (type=all) czy bardziej prawdopodobny skan indeksu (type=index), jednak wciąż w obrębie dnia będziemy mieć sort by znaleźć maksymalną czy minimalną wartość.
Dopiero denormalizacja i wprowadzenie dodatkowej kolumny zawierającej wyłącznie datę bez czasu oraz wprowadzenie podwójnego indeksu na (data,wartość) umożliwi nam dla zapytania typu

[SQL] pobierz, plaintext 
... WHERE `date` = CURDATE() ORDER BY `value` DESC LIMIT 1
[SQL] pobierz, plaintext 

pełne wykorzystanie tego indeksu (w explain będzie type=ref oraz ref=const) i możemy mieć w tabeli pierdyliard rekordów a wynik dostaniemy bardzo szybko - mysql znajdzie konkretne miejsce z danymi po indeksie btree w logarytmicznym czasie.

Wprawdzie przy INNER JOIN nie ma różnicy czy warunek złączenia wrzucisz do WHERE czy do ON, ale proponuję jednak korzystać z tej drugiej składni. Bo już przy LEFT JOIN różnica jest, a że będziesz potrzebować właśnie takiego typu złączenia do wyciągnięcia kategorii w sytuacji gdy artykuł może nie mieć przypisanej żadnej kategorii, to lepiej jednak dla czytelności mieć od razu widoczne po jakich kolumnach łączysz. Zresztą to dobra praktyka jest.

Jeśli chcesz mieć dla artykułu wiele rekordów każdy z inną kategorią to po prostu dodajesz dwie tabele łącząc articles_categories po id_articles oraz categories po id_category, a jeśli w jednym rekordzie listę kategorii oddzielonych przecinkiem to stosujesz GROUP BY i GROUP_CONCAT w podzapytaniu, czyli przykładowo:

[SQL] pobierz, plaintext 
SELECT a.title, a.content, u.name, cl.category_list
FROM articles a JOIN users u 
  ON a.id_user = u.id 
LEFT JOIN
  ( SELECT ac.id_articles, GROUP_CONCAT( c.name ) AS category_list
    FROM articles_categories ac JOIN categories c
      ON ac.id_category = c.id
    GROUP BY ac.id_articles ) cl
ON a.id = cl.id_articles
[SQL] pobierz, plaintext 

Diagramy pomagają przede wszystkim zrozumieć i ogarnąć zależności między tabelami. Na strukturę tych tabel przekładają się tylko jeśli stosuje się FOREIGN KEY w tabelach InnoDB. Wtedy jeśli jakieś pole z ustawionym FOREIGN KEY na inną tabelę jednocześnie ma primary albo unique key to wtedy można mówić o relacji jeden do jeden, jeśli to zwykły index to jeden do wielu. Przydaje się to jeśli chcemy zachować spójność bazy już na poziomie mysql, na przykład by niemożliwe było usunięcie kontrahenta, na którego wystawione są faktury.

W praktyce nie pamiętam kiedy ostatnio w projekcie jakiejś bazy używałem relacji jeden do jeden. Zazwyczaj łatwiej jest po prostu umieścić wszystko w jednej tabeli.
Właściwie zdecydowana większość relacji to jeden do wielu, ewentualnie wiele do wielu połączone przez dodatkową tabelę w środku.
Do tego większość baz danych jest projektowana w ogóle bez foreign keys, a spójność jest trzymana na poziomie aplikacji (przykładowo w interfejsie nie ma w ogóle możliwości usuwania kontrahentów, ewentualnie ustawia się jakąś flagę nieaktywności, a jeśli jest możliwość usuwania to dodatkowy kod robi coś konkretnego z powiązanymi fakturami).
Oczywiście nie staram się nikogo przekonywać do rezygnowania z foreign key, kaskadowe operacje chociażby są całkiem przyjemne w odpowiednich sytuacjach, ale taka jest rzeczywistość, często terminy wygrywają ze sztywnym trzymaniem ACID.

Od wersji mysql 5.5 InnoDB jest domyślnym silnikiem tabel tworzonych bez podania konkretnego silnika w CREATE TABLE.
Przedmówcy wyjaśnili, że inserty do InnoDB wykonują się szybciej albo zawarte w jednej transakcji, albo jako jeden duży insert, albo też przy wyłączonym na czas insertów autocommit. Bo bez tego każdy insert jest osobną transakcją (InnoDB to silnik transakcyjny, w przeciwieństwie do wcześniejszego domyślnego MyISAM) a każda nawet najmniejsza zakończona transakcja z definicji wymaga zapisania stanu na dysku zamiast trzymania w buforach.
Oczywiście powrot do MyISAM przywróci poprzedni stan działania, jednak w roku 2015 wypadałoby znać InnoDB, nie mówiąc o zaprzestaniu używania przestarzałych funkcji z API mysql_.

http://dev.mysql.com/doc/refman/5.5/en/inn...default-se.html

Ogólna zasada jest taka, że jeśli używamy GROUP BY, to do SELECT możemy wrzucić tylko kolumnę, według której grupujemy (lub jeśli grupujemy po kombinacji to tylko te kolumny) oraz wyrażenia zawierające funkcje agregujące z innymi kolumnami.

Mysql jest jedyną bazą, która nie pluje się na użycie dodatkowych kolumn - inne po prostu zwrócą syntax error, ale idą za tym ograniczenia - do wszystkich pozostałych kolumn bierze pierwsze z brzegu wartośći dla każdej grupy, mając przy tym całkowitą dowolność, najczęściej bierze więc wartości z tych rekordów, dla których wykona najmniej operacji I/O na dysku. Jeśli w każdej grupie dla danej kolumny mamy identyczne wartości to problemu nie ma, ale jeśli są różne to nie mamy absolutnie żadnej możliwości wpływania na rezultat, w szczególności ORDER BY na wynik nie wpływa, bo sortuje gotowe rekordy dawno po tym, jak do każdej grupy zostały wzięte jakieś wartości. Nawet jeśli chwilowo wyniki mogą się zgadzać z naszymi oczekiwaniami to proste zmiany w indeksach mogą nam mocno namieszać.

Należałoby najpierw znaleźć najnowszą wiadomość dla każdego usera - czyli z tabeli message SELECT user_id, MAX(id) przy GROUP BY user_id, czyli jesteśmy całkowicie pewni wszystkich wyników - user_id siedzi w GROUP BY, a MAX() jest funkcją agregującą, następnie ponownie dołączyć message wg tych dwóch kolumn by otrzymać odpowiadającą im treść wiadomości i dołączyć również tabelę konto by mieć pozostałe informacje o userze z danym user_id.

Skoro interesują nas wszystkie możliwe pary rekordów to w najgorszym przypadku będziemy mieć iloczyn kartezjanski przy self-joinie, ale możemy to nieco uprościć. Zakładając, że dwa rekordy są podobne jeżeli dla tego samego owocu mają taką samą ilość, to możemy dodać to jako warunek złączenia. W ten sposób pomijamy wszystkie pary, które nie mają ze sobą nic wspólnego a także dostajemy dane w formacie dość wygodnym do pogrupowania, bo wystarczy w każdej grupie dla identycznych par ID policzyć rekordy i otrzymujemy liczbę zgodnych pozycji zakupów. Czyli:

[SQL] pobierz, plaintext 
SELECT z1.ID AS ID1, z2.ID AS ID2, COUNT(*) AS podobienstwo
FROM zakupy z1 JOIN zakupy z2
ON z1.ID < z2.ID AND z1.Owoc = z2.Owoc AND z1.Ilosc = z2.Ilosc
GROUP BY z1.ID, z2.ID
ORDER BY podobienstwo DESC, z1.ID, z2.ID
[SQL] pobierz, plaintext 

UNIQUE można założyć nie tylko na pojedyncze kolumny, ale również na kombinacje kolumn, czyli na przykład jeśli na razie w tabeli nie ma powtórzeń, których chcesz uniknąć, to wystarczy

[SQL] pobierz, plaintext 
ALTER TABLE tabela ADD UNIQUE( ID_prowadzonekontrole, Name );
[SQL] pobierz, plaintext 

Wtedy każda z tych kolumn z osobna może mieć powtarzane wielokrotnie te same wartości, ale ich para musi już być unikalna.
INSERT INGORE powinno wówczas prawidłowo zrobić to czego oczekujesz.

Fulltext-fine-tuning



W indeksie fulltext znajduje się lista słów wraz z odpowiadającymi im informacjami, w którym rekordzie się znajdują, jak często itp.
Mysql nie musi szukać pełnych tekstów w rekordach, wystarczy że zajrzy do tego indeksu.

Patrząc na ten kod, pomijając ile razy coś tam się wyświetla a ile razy powinno, można sobie wyobrazić następującą sytuację:

Przychodzi czytelnik do biblioteki, prosi o wszystkie książki w bibliotece i sprawdza po kolei kto je napisał, porównując nazwisko autora z "X".
Gdy znajdzie taką książkę, prosi o listę wszystkich książek napisanych w roku Y i sprawdza czy ta książka znajduje się na tej liście.
Niezależnie od wyniku, odnosi listę z powrotem i szuka kolejnej pasującej książki, za każdym razem biorąc tę samą listę i odnosząc ją z powrotem.
Bibliotekarka trochę krzywo się patrzy, ale że jest inteligentna to nie odkłada tej listy na półkę, tylko trzyma ją w pogotowiu (query cache).
Po miesiącu czytelnik znajduje wszystko to co chciał i dziękuje bibliotekarce za cierpliwość i chce wychodzić, ale słyszy pytanie:
- Dlaczego po prostu nie poprosił pan o książki napisane przez X w roku Y?
- A to pani tak potrafi?

Otóż tak, baza danych (bibliotekarka) potrafi takie rzeczy i robi to o wiele szybciej wykorzystując sobie znane mechanizmy takie jak na przykład indeksy (katalogi książek).
Wygląda na to, że napisałeś od nowa implementację WHERE oraz JOIN, wymagającą przesłania całych tabel między mysql a php i bez żadnych usprawnień, które mysql oferuje.

A przecież wystarczy odpowiednio zapytać (nie podałeś struktur tabel, więc trzeba je zgadywać z kodu):

[SQL] pobierz, plaintext 
SELECT pk.id AS id_panelu, pkw.id AS id_wiadomosci, pk.nick AS nick_autora, pkw.nick AS nick_odpowiedzi, pk.STATUS, pkw.tresc
FROM panel_kontaktowy pk JOIN panel_kontaktowy_wiadomosci pkw ON pk.id = pkw.id_panelu
WHERE pk.nick = 'Damian'
ORDER BY pk.id, pkw.id
[SQL] pobierz, plaintext 

Otrzymujesz jeden obcięty zestaw, w całości do wyświetlenia, jedyne co musisz dodać to jakieś przerywniki gdy zmienia się id_panelu by oddzielić od siebie różne wątki.

Jeśli użyjemy takiego joina to właściwie cały ten IF możemy zastąpić SELECT 1 AS isFavs, zapewnia to sam warunek złączenia, a nie przypuszczam by o to autorowi chodziło.
W ogóle ciężko stwierdzić o co chodziło, bo jesteśmy przygniecieni ogromem informacji zawartych w stwierdzeniu "ale to nie dział".
Prawidłową odpowiedzią na najbardziej prawdopodobny scenariusz czyli autorowi chodziło o to, by wyświetlić wszystkie posty oraz informację czy dany post znajduje się w czyichkolwiek ulubionych byłoby poprawienie oczywistego błędu składniowego - zamiana fav_id na post_id, bo pola fav_id nie ma w strukturze tabel. Obawiam się jednak, że nadal możemy otrzymać odpowiedź "wciąż nie dział".
Jeśli jednak o to właśnie chodzi, a mamy użyć do tego joina, zamiast całkiem wolnego IN( ), to lepiej byłoby:

[SQL] pobierz, plaintext 
SELECT DISTINCT posts.* , ulubione.post_id IS NOT NULL AS isFavs
FROM posts LEFT JOIN ulubione ON posts.id = ulubione.post_id
[SQL] pobierz, plaintext 

To co aktualnie robi ten kod:

1. Pobierz wszystkie rekordy, w szczególności $haslo.
2. Dla każdego rekordu wykonaj : w kolumnie md5_haslo ustaw md5($haslo) dla całej tabeli.

Krótko mówiąc dla każdego hasła wielokrotnie zmieniasz całą tabelę, w związku z tym na sam koniec zostaje w całej tabeli ustawione haslo_md5 na hash ostatniego rekordu.
Samo zapytanie mysql:

[SQL] pobierz, plaintext 
UPDATE `kody` SET `haslo_md5` = MD5( `haslo` );
[SQL] pobierz, plaintext 

zrobi dokładnie to co potrzebujesz, to jest update na całą tabelę, dla każdego rekordu ustawi odpowiedni dla jego hasła hash. Nie potrzeba nic z bazy wcześniej wyciągać, nawet php do tego nie jest potrzebny, wystarczy wklepać to w konsoli mysql, phpmyadminie czy jakimkolwiek innym kliencie mysql.

Szczerze mówiąc oba sposoby przy takiej składni nie powinny działać, czy czasem nie zrobiłeś gdzieś błędu przy wklejaniu kodu?
Albo definiujesz zmienną $pdo i wtedy używasz jej w zakresie jej widoczności, czyli tak jak prawdopodobnie wygląda drugi działający sposób:

[PHP] pobierz, plaintext 
public function addUser()
{
  $pdo = Database::getDB();
  $pdo->exec(...);
}
[PHP] pobierz, plaintext 

albo też definiujesz jako property dla klasy i wtedy używasz tak:

[PHP] pobierz, plaintext 
public function __construct()
{
  $this->pdo = Database::getDB();
}
 
public function addUser()
{
 $this->pdo -> exec(...);
}
[PHP] pobierz, plaintext 

Poza tym w obu przypadkach wykorzystujesz istniejące już połączenie z bazą. Gwarantuje to klasa Database zrobiona jako singleton, getDB() zwraca tą samą instancję klasy PDO za każdym razem lub ewentualnie tworzy ją jeśli jej jeszcze nie ma.

Nie widzę przeszkód by łączyć dwukrotnie do tej samej tabeli (pod innymi aliasami), za pierwszym razem by dostać dane autora, za drugim by dostać dane ostatniego wypowiadającego się w temacie.
Wtedy limit 20 będzie dotyczył pojedyńczych tematów.
Poza tym, jeśli w każdym temacie oba pola są wypełnione (jeśli nikt nie odpowiedział to post startowy traktujemy jako ostatni, więc oba id są identyczne), a użytkownicy nie są kasowani ani nie zmieniają id, to nie jest potrzebny LEFT JOIN, wystarczy zwykły JOIN ( czyli INNER JOIN precyzyjnie ujmując ).

Jeśli zmienia się tylko ostatnia część to wystarczy:

[PHP] pobierz, plaintext 
  $mac1 = '0F:69:6D:4F:B9:03';
  $mac2 = '0F:69:6D:4F:B9:1C';
 
  $base = substr( $mac1, 0, 15 );
  $offset1 = substr( $mac1, 15 );
  $offset2 = substr( $mac2, 15 );
 
  for( $i = hexdec($offset1); $i<=hexdec($offset2); $i++ )
    echo $base.sprintf('%02X',$i).'<br />';
[PHP] pobierz, plaintext 

Jeśli zmienia się więcej to trzeba usunąć dwukropki z offsetów przy pomocy str_replace() przed zamianą na dec, a przy wyświetlaniu wstawić z powrotem przez wordwrap().

Zapytanie trwa długo, bo robisz wielki left join z kilku tabel, grupujesz wszystko i dopiero filtrujesz gotowe grupy przy pomocy HAVING, czyli robisz wszystko od końca.
Left join stosujemy wtedy, gdy chcemy wszystkie rekordy z lewej tabeli wraz z odpowiadającymi wg warunku ON rekordami z prawej tabeli, a gdy takich w prawej tabeli nie ma to wciąż chcemy rekordy z lewej, tyle że w prawej zamiast wartości będa NULL. Natomiast INNER JOIN ( można pisać sam JOIN ) wybiera tylko te rekordy, które potrzebujemy - jeśli w obu tabelach nie ma takich wspólnie spełniajacych warunek złączenia to prostu są ignorowane.

W tym wypadku powinieneś zacząć od warunku w nazwą podkategorii w zwykłym WHERE i powoli rozbudowywać swój rowset dodając potrzebne JOIN, nie widzę potrzeby by to były LEFT JOIN.

Jeśli potrzebujesz zapytania, to wyjaśnij dokładniej o co chodzi, najlepiej na konkretnym przykładzie zawierającym kilka profili, kategorii i podkategorii i podaj oczekiwany wynik.

Jeśli chodzi o wypisanie możliwych kolorów z trzech różnych kolumn to wystarczy:

[SQL] pobierz, plaintext 
SELECT DISTINCT(kolor1) AS kolor FROM przedmiot
UNION SELECT DISTINCT(kolor2) AS kolor FROM przedmiot
UNION SELECT DISTINCT(kolor3) AS kolor FROM przedmiot
ORDER BY kolor
[SQL] pobierz, plaintext 

[PHP] pobierz, plaintext 
$dbh = new PDO( ... );
...
$query = "SELECT imie, nazwisko, MAX(wyplata) AS 'maxwyplata' FROM pracownicy GROUP BY imie, nazwisko HAVING maxwyplata > :getwyplata";
$stmt = $dbh->prepare( $query );
$stmt->bindParam( ':getwyplata', $getwyplata, PDO::PARAM_INT );
$stmt->execute();
[PHP] pobierz, plaintext 

Skoro już znalazłeś taką funkcję to mam nadzieję, że przeczytałeś do niej manual, gdzie w wielkim czerwonym oknie na samej górze napisane jest, że już w tej chwili wszystkie funkcje z mysql_ są przestarzałe, a w przyszłych wersjach będą w ogóle usunięte.
W zasadzie nie rozumiem dlaczego dyskutujecie na temat jak zabezpieczyć kod typu mysql_ zamiast dyskutować o tym że w ogóle nie należy go stosować. Serio, PDO nie jest takie straszne jak się wydaje, a parametryzowane wywołania zupełnie eliminują problem SQL injection. Wciąż trzeba uważać na XSS jeśli wypluwamy na stronę jakikolwiek html z bazy, ale to i tak duży postęp w stosunku do tego na co trzeba uważać z mysql_.

To jest do zrobienia, ale prawdę powiedziawszy nie powinieneś dostać odpowiedzi, bo widząc taką strukturę danych to nóż się otwiera w kieszeni.
Raczkujesz, więc nie utrwalaj sobie złych nawyków. Jeśli przykładowo skasujesz jakąś datę to co z pozostałymi danymi? Mają przejść na poprzednią? Czy znowu masz szukać następnej i kasować również wszystko aż do niej?
Prawidłowo powinno wyglądać to tak, że masz dwie tabele, w jednej trzymasz dane z datami i tymi 'ok' a w drugiej odpowiadające im 'a','b' i tak dalej.
Przykładowo tabela `pytania` (to tylko domysł co te dane mają modelować) mogłaby mieć kolumny id, czas, sprawdz, natomiast tabela `odpowiedzi` id, id_pytania, dane.
Czyli klasyczna relacja jeden do wielu, gdzie id_pytania w tabeli odpowiedzi jest zewnętrznym kluczem do id w tabeli pytania.
Wówczas wystarczyłoby:

[SQL] pobierz, plaintext 
SELECT o.dane FROM pytania p JOIN odpowiedzi o ON p.id = o.id_pytania WHERE p.czas='2013_04_24/17:02:11'
[SQL] pobierz, plaintext 

Swoją drogą te daty (i czasy) powinny być typu DATETIME, mysql udostępnia tłum funkcji i operatorów do działań na datach nie po to żeby zapełnić czymś manual i nie świecił pustkami.
Zwykłe odjęcie jakiegoś odstępu czasu by odpowiedzieć na proste pytanie które rekordy powstały w ciągu ostatniego miesiąca to w przypadku pola DATETIME: czas - INTERVAL 1 MONTH, a na stringu wymaga to konwersji i wielu obliczeń, pamiętania o jakichś bzdurach typu rok przestępny itp, ewentualnie korzystania z funkcji zewnętrznego języka. I po co, skoro mysql robi to bezbłędnie i szybko?
Oczywiście jeśli w tym samym polu trzymasz jakieś 'a' to naturalnie ustawienie DATETIME nie jest możliwe, ale po rozdzieleniu można przynajmniej zrobić to prawidłowo.

[SQL] pobierz, plaintext 
UPDATE tabela
SET wynik2 = concat_ws( [TO samo co wczesniej] )
[SQL] pobierz, plaintext 

Oczywiście zamieniając wszystkie wystąpienia 'kolumna' na 'wynik'.