Drukowana wersja tematu

Kliknij tu, aby zobaczyć temat w orginalnym formacie

Forum PHP.pl _ Przedszkole _ [MySQL][PHP][SQL]Usuwanie wszystkich rekordów poza 1 kolumną

Napisany przez: Nidan23 14.06.2019, 19:33:02

Czy jest jakakolwiek opcja, żeby usunąć wszystko z tabeli poza 1 kolumną?

Napisany przez: Tomplus 14.06.2019, 22:07:41

Ogarnij jeszcze raz pytanie. Bo ja do końca nie rozumiem czy chodzi ci o kolumny tabeli MySQL czy o wiersze?

Napisany przez: Nidan23 15.06.2019, 11:07:01

Cytat(Tomplus @ 14.06.2019, 23:07:41 ) *
Ogarnij jeszcze raz pytanie. Bo ja do końca nie rozumiem czy chodzi ci o kolumny tabeli MySQL czy o wiersze?



Wybacz, źle opisałem, usunąć wszystkie wiersze z tabeli, poza ich zawartością w jednej kolumnie

Napisany przez: Tomplus 15.06.2019, 12:02:50

Czyli nie chcesz usuwać wierszy, tylko wyczyścić wartości.

[SQL] pobierz, plaintext 
  1. UPDATE tabela SET value=NULL, valueX = NULL, valueY = NULL;
[SQL] pobierz, plaintext

Napisany przez: dublinka 15.06.2019, 12:36:22

Cytat(Nidan23 @ 14.06.2019, 19:33:02 ) *
Czy jest jakakolwiek opcja, żeby usunąć wszystko z tabeli poza 1 kolumną?


Jak czytam Twoje posty to mnie 'czepie'

Napisany przez: Nidan23 15.06.2019, 13:23:47

Cytat(Tomplus @ 15.06.2019, 13:02:50 ) *
Czyli nie chcesz usuwać wierszy, tylko wyczyścić wartości.

[SQL] pobierz, plaintext 
  1. UPDATE tabela SET value=NULL, valueX = NULL, valueY = NULL;
[SQL] pobierz, plaintext



Ehhh, miałem nadzieję na jakieś polecenie typu , "Delete from Klan except ..."

To akurat wiedziałem, mówię, żeby nie wyjść na kompletnego debila.

Dzięki za pomoc smile.gif

Napisany przez: Tomplus 15.06.2019, 13:30:28

DELETE usuwa wiersze.
A ty chcesz pozstawić kolumnę, więc wierszy nie możesz usunąć.

ewenetualnie

[SQL] pobierz, plaintext 
  1. ALTER TABLE tabela DROP COLUMN value, DROP COLUMN valueX;
[SQL] pobierz, plaintext

Usuwa tylko wybrane kolumny

Napisany przez: Nidan23 15.06.2019, 14:31:22

Dobra, obędzie się bez tego, coś wykombinuje na moim poziomie wiedzy, ale dzięki za pomoc wink.gif

Napisany przez: Pyton_000 16.06.2019, 10:46:03

Znając życie masz zupełnie inny problem a próbujesz się do niego dobrać od dupy strony.

Napisany przez: Nidan23 16.06.2019, 13:09:15

Cytat(Pyton_000 @ 16.06.2019, 11:46:03 ) *
Znając życie masz zupełnie inny problem a próbujesz się do niego dobrać od dupy strony.


Znając życie tak, znając sytuacje nie, bo tak kolumna to 1 pojawienie się rekordu w tabeli i nie chcę go usuwać czyszcząc tabele co miesiąc, co jest jednym z założeń mojej strony i ich gry, sooooo nie da się i trudno

Napisany przez: Pyton_000 16.06.2019, 13:51:30

Pokaż przykład co masz i co byś chciał mieć

Napisany przez: Nidan23 16.06.2019, 14:01:16

Cytat(Pyton_000 @ 16.06.2019, 14:51:30 ) *
Pokaż przykład co masz i co byś chciał mieć


Ale tu nie ma czego pokazywać, schemat tabeli wygląda tak:

[SQL] pobierz, plaintext 
  1. CREATE TABLE IF NOT EXISTS `explayers` (
  2.   `miejsce` int(11) DEFAULT NULL,
  3.   `liga` varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
  4.   `poziom` int(11) DEFAULT NULL,
  5.   `tag` varchar(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  6.   `nick` varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
  7.   `ranga` varchar(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  8.   `donated` int(11) DEFAULT NULL,
  9.   `sdonated` int(11) DEFAULT NULL,
  10.   `rdonated` int(11) DEFAULT NULL,
  11.   `received` int(11) DEFAULT NULL,
  12.   `roznica` int(11) DEFAULT NULL,
  13.   `puchary` int(11) DEFAULT NULL,
  14.   `warstars` int(11) DEFAULT NULL,
  15.   `swarstars` int(11) DEFAULT NULL,
  16.   `rwarstars` int(11) DEFAULT NULL,
  17.   `gamedon` int(22) DEFAULT NULL,
  18.   `awin` int(11) DEFAULT NULL,
  19.   `dwin` int(11) DEFAULT NULL,
  20.   `th` int(3) DEFAULT NULL,
  21.   `elixir` int(22) DEFAULT NULL,
  22.   `selixir` int(22) DEFAULT NULL,
  23.   `uelixir` int(22) DEFAULT NULL,
  24.   `gold` int(22) DEFAULT NULL,
  25.   `sgold` int(22) DEFAULT NULL,
  26.   `ugold` int(22) DEFAULT NULL,
  27.   `dark` int(22) DEFAULT NULL,
  28.   `sdark` int(22) DEFAULT NULL,
  29.   `udark` int(22) DEFAULT NULL,
  30.   `cwls` int(11) DEFAULT NULL,
  31.   `scwl` int(11) DEFAULT NULL,
  32.   `rcwl` int(11) DEFAULT NULL,
  33.   `cg` int(11) DEFAULT NULL,
  34.   `scg` int(11) DEFAULT NULL,
  35.   `rcg` int(11) DEFAULT NULL,
  36.   `cc` int(2) DEFAULT NULL,
  37.   `gstar` int(4) DEFAULT NULL,
  38.   `aktualizacja` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  39.   `data` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  40.   `ppc` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  41.   `ppd` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  42.   `pk` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL
  43. ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
[SQL] pobierz, plaintext



ppc => pierwsze pojawienie czas - godzina:minuta;

Sezon w grze trwa około 30 dni i wtedy resetują się statystyki, więc i ja opróżniam tabelę, ale chcę jakoś zatrzymać pierwsze pojawienie, bo to oznacza kiedy gracz przyszedł do nas.


Jednak właśnie uświadomiłem sobie, że mogę to zrobić inaczej, biorąc dane z tabel z poprzednich miesięcy/sezonów i użyć UPDATE, więc uważam temat za zamknięty, dzięki wink.gif

Napisany przez: Tomplus 16.06.2019, 14:25:29

I sam widzisz, źle zaprojektowałeś sobie bazę danych. Uniemożliwiasz sobie stworzenie historii rozgrywek.

Bo nie lepiej byłoby rozdzielić tą tabelę na więcej tabel?

explayers
id, nick, ppc

exgames
season, idExplayer, liga, poziom, gold... etc...


Napisany przez: Nidan23 27.06.2019, 13:22:04

Cytat(Tomplus @ 16.06.2019, 15:25:29 ) *
I sam widzisz, źle zaprojektowałeś sobie bazę danych. Uniemożliwiasz sobie stworzenie historii rozgrywek.

Bo nie lepiej byłoby rozdzielić tą tabelę na więcej tabel?

explayers
id, nick, ppc

exgames
season, idExplayer, liga, poziom, gold... etc...


Niesądzę, ponieważ wtedy, aby wyświetlić dane w tabeli, czy wykresie musiałbym pobierać dane z 2 tabel, a w dodatku te wszystkie dane (bo nie jestem pewny czy zauważyłeś, nie dziwię się jeśli nie) dotyczą tego samego gracza - 1 wiersz = 1 gracz, więc aby pobierać dane, musiałbym mieć jakiekolwiek rozeznanie, kto jest kim, a jedyną unikalną rzeczą jest tag, więc wszystko siedzi w jednej tabeli.

Napisany przez: SmokAnalog 27.06.2019, 13:35:34

Tomplus ma rację - baza jest źle zaprojektowana. Baz nie projektuje się w poziomie, bo potem napotykasz na absurdalne problemy tak jak ten tutaj.

Co jest złego w pobieraniu danych z dwóch tabel? Płacisz złotówkę od każdej tabeli w zapytaniu czy jak?

Napisany przez: Tomplus 28.06.2019, 18:55:03

@Nidan
Kiedyś uważałem tak samo. Dopóki nie trafiłem na problem który masz teraz.
Też miałem stronę gdzie było 1 gracz = 1 wiersz, więcej nie było potrzeba gdy strona była prosta, gdy rosła, kolejne funkcje były dodawane, to myślenie powodowały problemy. Najgorsze jest to że czasem dochodzi do takiego momentu że aby coś robić dalej, musisz przeprojektować bazę, a przeprojektowanie bazy powoduje że trzeba przeprojektować wiele aspektów serwisu.


Napisany przez: Nidan23 28.06.2019, 21:48:57

Cytat(Tomplus @ 28.06.2019, 19:55:03 ) *
@Nidan
Kiedyś uważałem tak samo. Dopóki nie trafiłem na problem który masz teraz.
Też miałem stronę gdzie było 1 gracz = 1 wiersz, więcej nie było potrzeba gdy strona była prosta, gdy rosła, kolejne funkcje były dodawane, to myślenie powodowały problemy. Najgorsze jest to że czasem dochodzi do takiego momentu że aby coś robić dalej, musisz przeprojektować bazę, a przeprojektowanie bazy powoduje że trzeba przeprojektować wiele aspektów serwisu.


A gdy dodać coś w tylu:

[PHP] pobierz, plaintext 
  1.   $sql = "SELECT PierwszePojawnie FROM 1";
  2.   $conn->query('SET NAMES utf8');
  3. $conn->query('SET CHARACTER_SET utf8_unicode_ci');
  4. $result = $conn->query($sql);
  5.  
  6. if ($result->num_rows > 0) {
  7.  blablabla
  8. }
  9.   else {$sql = "SELECT PierwszePojawnie FROM tabela2";
  10.   $conn->query('SET NAMES utf8');
  11. $conn->query('SET CHARACTER_SET utf8_unicode_ci');
  12. $result = $conn->query($sql);
  13. if ($result->num_rows > 0) {
  14.  blablabla
  15. }
  16. }
[PHP] pobierz, plaintext


itd.? Ja wiem, to jest zła optymalizacja i sporo zabawy, bo co miesiąc musiałbym dodawać dodatkową część do skryptu, ale tak całkowicie teoretycznie, miałoby to szanse działać?
(spokojnie, nie mam zamiaru tego robić, bo już mam wzór bazy w głowie po przebudowaniu)

Napisany przez: Tomplus 29.06.2019, 09:35:45

Lepsze jest rozwiążanie:

[SQL] pobierz, plaintext 
  1. SELECT listaLogowan.PierwszePojawienie, listaGraczy.nazwa  FROM listaGraczy LEFT JOIN listaLogowan ON listaGraczy.id = listaLogowan.idGracza WHERE listaLogowan.idGracza = ? ORDER BY listaLogowan.czasLogowania LIMIT 1;
[SQL] pobierz, plaintext


listaLogowan = listaAktywnosci etc...

Jedno zapytanie, dwie tabele.
Spokojnie można łączyć więcej niż jedną tabelę.

Np. masz listę statusów użytkownika:
1. Administrator
2. Moderator
3. Gracz
4. Zbanowany

w tabeli z użytkownikami masz kolumnę `status` i nie piszesz tam że ktoś jest adminem, a ktoś modem, a tylko dajesz informację cyfrową.
W kodzie nie robisz tablicy: $statusyGraczy = []; Bo okaże się że w wielu skryptach będziesz musiał powtarzać takie tablice, a gdzieś nie powtórzysz i wyjdzie Ci błąd.

Dodatkowo, dzięki temu możesz nadawać specjalne informacje dla danego statusu i wykorzystać w zapytaniu. Teraz będziesz to robił dodając specjalną kolumnę dla każdego użytkownika.

Napisany przez: Nidan23 30.06.2019, 14:47:09

Cytat(Tomplus @ 28.06.2019, 19:55:03 ) *
@Nidan
Kiedyś uważałem tak samo. Dopóki nie trafiłem na problem który masz teraz.
Też miałem stronę gdzie było 1 gracz = 1 wiersz, więcej nie było potrzeba gdy strona była prosta, gdy rosła, kolejne funkcje były dodawane, to myślenie powodowały problemy. Najgorsze jest to że czasem dochodzi do takiego momentu że aby coś robić dalej, musisz przeprojektować bazę, a przeprojektowanie bazy powoduje że trzeba przeprojektować wiele aspektów serwisu.


Myślisz, że taka taki schemat jest rozsądniejszy? Wtedy co sezon czyszczę tylko jedną tabelę (klandata) a z drugiej zwyczajnie są usuwane osoby nie będące już w tym klanie.

[SQL] pobierz, plaintext 
  1. CREATE TABLE IF NOT EXISTS `klanplayers` (
  2.   `miejsce` int(11) DEFAULT NULL,
  3.   `tag` varchar(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  4.   `nick` varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
  5.   `ranga` varchar(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  6.   `aktualizacja` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  7.   `data` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  8.   `ppc` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  9.   `ppd` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  10.   `ak` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  11.   `cb` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL
  12. ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
  13.  
  14. CREATE TABLE IF NOT EXISTS `klandata` (
  15.   `miejsce` int(11) DEFAULT NULL,
  16.   `liga` varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
  17.   `poziom` int(11) DEFAULT NULL,
  18.   `tag` varchar(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  19.   `nick` varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
  20.   `donated` int(11) DEFAULT NULL,
  21.   `sdonated` int(11) NOT NULL,
  22.   `rdonated` int(11) DEFAULT NULL,
  23.   `received` int(11) DEFAULT NULL,
  24.   `roznica` int(11) DEFAULT NULL,
  25.   `puchary` int(11) DEFAULT NULL,
  26.   `warstars` int(11) DEFAULT NULL,
  27.   `swarstars` int(11) DEFAULT NULL,
  28.   `rwarstars` int(11) DEFAULT NULL,
  29.   `gamedon` int(22) DEFAULT NULL,
  30.   `awin` int(11) DEFAULT NULL,
  31.   `dwin` int(11) DEFAULT NULL,
  32.   `th` int(3) DEFAULT NULL,
  33.   `elixir` int(22) DEFAULT NULL,
  34.   `selixir` int(22) DEFAULT NULL,
  35.   `uelixir` int(22) DEFAULT NULL,
  36.   `gold` int(22) DEFAULT NULL,
  37.   `sgold` int(22) DEFAULT NULL,
  38.   `ugold` int(22) DEFAULT NULL,
  39.   `dark` int(22) DEFAULT NULL,
  40.   `sdark` int(22) DEFAULT NULL,
  41.   `udark` int(22) DEFAULT NULL,
  42.   `cwls` int(11) DEFAULT NULL,
  43.   `scwl` int(11) DEFAULT NULL,
  44.   `rcwl` int(11) DEFAULT NULL,
  45.   `cg` int(11) DEFAULT NULL,
  46.   `scg` int(11) DEFAULT NULL,
  47.   `rcg` int(11) DEFAULT NULL,
  48.   `cc` int(2) DEFAULT NULL,
  49.   `gstar` int(4) DEFAULT NULL
  50. ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
[SQL] pobierz, plaintext

Napisany przez: Tomplus 1.07.2019, 05:21:43

Za dużo kolumn, będzie za dużo ograniczeń.
Ale jeżeli to coś prostego, bez rozwoju na przyszłość. To wystarczy.


Jednakże, ani w jednej ani w drugiej tabeli nie masz ID rzędu.
W obydwóoch masz `nick` jako string, jak Ty chcesz zarządzać użytkownikami?

SELECT * FROM klandata WHERE nick = 'Nidan'?


Napisany przez: Nidan23 1.07.2019, 14:08:05

Cytat(Tomplus @ 1.07.2019, 06:21:43 ) *
Za dużo kolumn, będzie za dużo ograniczeń.
Ale jeżeli to coś prostego, bez rozwoju na przyszłość. To wystarczy.


Jednakże, ani w jednej ani w drugiej tabeli nie masz ID rzędu.
W obydwóoch masz `nick` jako string, jak Ty chcesz zarządzać użytkownikami?

SELECT * FROM klandata WHERE nick = 'Nidan'?


Nope, SELECT * FROM klandata WHERE tag = '#RYJQPO', bo tag jest unikalny. Chociaż pomysł rozbicia tego na generalnie tabele tematyczne, np. ufarmione surowce etc nie jest głupie, hmmm

Napisany przez: Tomplus 1.07.2019, 23:02:56

Właśnie, posługiwanie się ciągiem znaku do identyfikowania rekordów w tabeli rzadko jest dobrym pomysłem. Przy małych projektach jest to nieodczuwalne, ale przy dużych lepiej używać ID liczbowych.

Napisany przez: com 2.07.2019, 08:01:50

Niekoniecznie, dziś dużo systemów używa np UUID, ale taki krótki identyfikator faktycznie nie jest dobrym pomysłem bo pula ich jest ograniczona wink.gif

Napisany przez: Tomplus 2.07.2019, 09:09:15

To prawda że dużo systemów używa UUID, ale aby opierać identyfikatory na ciągach znaków to jest to bardziej przemyślane i takie zapytania muszą być szybkie. Jednakże stosowanie tego może zwolnić bazę danych. Bo aktualnie popularna baza danych MySQL nie do końca radzi sobie z takimi stringami.

Dlatego dla naszego kolegi to rozwiązanie może nie być efektywne, chociaż i tak lepsze niż ten dziwny tag.



Napisany przez: com 2.07.2019, 10:07:15

no tak, masz rację wink.gif

Napisany przez: Nidan23 2.07.2019, 10:35:00

Cytat(Tomplus @ 2.07.2019, 10:09:15 ) *
To prawda że dużo systemów używa UUID, ale aby opierać identyfikatory na ciągach znaków to jest to bardziej przemyślane i takie zapytania muszą być szybkie. Jednakże stosowanie tego może zwolnić bazę danych. Bo aktualnie popularna baza danych MySQL nie do końca radzi sobie z takimi stringami.

Dlatego dla naszego kolegi to rozwiązanie może nie być efektywne, chociaż i tak lepsze niż ten dziwny tag.


Ten dziwny tak to tylko przykład. Ja chętnie bym używał ID, jednak jest to całkowicie bezsensowne, ponieważ w klanie każdy na swoje miejsce, więc już mam liczbę a w dodatku pobieram informacje z API a lista graczy się zmienia, więc tag jest idealny + usuwanie rekordów opiera się na date(), więc kiedy aktualizacja jest różna od daty to usuwa i jest to na końcu, po zaktualizowaniu wszystkiego, więc nadanie Primary Key na 'miejsce' spowoduje błędy, a nawet bez Primary Key beda błędy, bo np. będą 2 rekordy z takim samym miejscem, to jak ma się aktualizować? A to pewnie zaburzy działanie skryptu usuwającego. Więc jak mówiłem, akurat to jest przemyślane.

Napisany przez: Tomplus 2.07.2019, 10:53:26

Każdy w klanie ma swoje miejsce?
- to każde miejsce ma swoje ID
- każdy gracz także ma swoje ID
- każdy klan ma także swoje ID
- jak ktoś ma miecz, albo worek ze złotem, to ten worek czy miecz także powinien mieć swoje ID...

Więc klan o ID:1 może mieć w ciągu tygodnia kilku graczy i pierwszy miał 1, ostatni może mieć już np. 34
każdy ma swój worek ze złotem, więc worek od ID:1 można przekazać do gracza o ID:1 albo 34. A może go wyrzucić/usunąć.
Nowy worek który gracz ID:1 kupi, zdobędzie będzie już miał inne id, kolejne unikalne.

W efekcie... opierasz się od ID dla każdego zbioru danych.


Jeżeli koniecznie potrzebujesz te tagi, to one też powinny mieć swoje ID:

ID:1 - TAG: HUASDS
ID:2 - TAG: SMESDS
...

Napisany przez: Nidan23 2.07.2019, 11:10:41

No dobra, będą mieć te ID i co mi po nich? Bo tabela klanu jest zmienna, raz ten jest 1, raz ten. Ale co mi da to, że każdy będzie mieć ID w tym przypadku? Cały skrypt aktualizacji jest w pętli i aktualizuje każdego pokolei według ich miejsca w klanie, które jak mówiłem jest zmienne, więc jedyną możliwościa identyfikacji rekordu jest tag, bo inne wymaga kombinacji.

PS. Żeby nie było, nie opieram się tam pomysłowi ID, bo tak, po prostu uważam to za zbędny bajer w tym przypadku, w tabeli użytkowników zarejestrowanych rzeczywiście mam takie coś, ale to jest już tabela powiedzmy "Kontrolowana", której aktualizacja odbywa się całkowicie manualnie i pobierany jest maksymalnie/aktualizowany jest max 1 rekord na raz. Nie używam tu zewnętrznych informacji i dla mnie tu ma to sens

Używanie tagu to najprostszy sposób na optymalizację zapytania, które nie może z resztą trwać dłużej niż minutę, bo wtedy usunie rekordy z datą inną niż obecna, a czasem w klanie jest 50 kont, więc no muszę stanąć przeciwko realiom...

Napisany przez: Tomplus 2.07.2019, 21:16:27

Czy wiesz, że to co robisz tym tagiem także jest identyfikatorem? Tylko że zamiast opierać o liczbę, opierasz o ciąg znaków.
Potem mówisz że szukasz optymalizacji zapytań smile.gif

Oczywiście przy małych bazach danych tego nie odczujesz, ale przy wiekszym ruchu już tak.


Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)