[MySQL][PHP][SQL]Usuwanie wszystkich rekordów poza 1 kolumną Opcje

[Nidan23]

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

[Tomplus]

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

[Nidan23]

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

[Tomplus]

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

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

[dublinka]

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

Jak czytam Twoje posty to mnie 'czepie'

[Nidan23]

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

[SQL] pobierz, plaintext 
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 (IMG:style_emoticons/default/smile.gif)

[Tomplus]

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

ewenetualnie

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

Usuwa tylko wybrane kolumny

[Nidan23]

Dobra, obędzie się bez tego, coś wykombinuje na moim poziomie wiedzy, ale dzięki za pomoc (IMG:style_emoticons/default/wink.gif)

[Pyton_000]

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

[Nidan23]

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

[Pyton_000]

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

[Nidan23]

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

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

[SQL] pobierz, plaintext 
CREATE TABLE IF NOT EXISTS `explayers` (
  `miejsce` int(11) DEFAULT NULL,
  `liga` varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
  `poziom` int(11) DEFAULT NULL,
  `tag` varchar(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  `nick` varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
  `ranga` varchar(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  `donated` int(11) DEFAULT NULL,
  `sdonated` int(11) DEFAULT NULL,
  `rdonated` int(11) DEFAULT NULL,
  `received` int(11) DEFAULT NULL,
  `roznica` int(11) DEFAULT NULL,
  `puchary` int(11) DEFAULT NULL,
  `warstars` int(11) DEFAULT NULL,
  `swarstars` int(11) DEFAULT NULL,
  `rwarstars` int(11) DEFAULT NULL,
  `gamedon` int(22) DEFAULT NULL,
  `awin` int(11) DEFAULT NULL,
  `dwin` int(11) DEFAULT NULL,
  `th` int(3) DEFAULT NULL,
  `elixir` int(22) DEFAULT NULL,
  `selixir` int(22) DEFAULT NULL,
  `uelixir` int(22) DEFAULT NULL,
  `gold` int(22) DEFAULT NULL,
  `sgold` int(22) DEFAULT NULL,
  `ugold` int(22) DEFAULT NULL,
  `dark` int(22) DEFAULT NULL,
  `sdark` int(22) DEFAULT NULL,
  `udark` int(22) DEFAULT NULL,
  `cwls` int(11) DEFAULT NULL,
  `scwl` int(11) DEFAULT NULL,
  `rcwl` int(11) DEFAULT NULL,
  `cg` int(11) DEFAULT NULL,
  `scg` int(11) DEFAULT NULL,
  `rcg` int(11) DEFAULT NULL,
  `cc` int(2) DEFAULT NULL,
  `gstar` int(4) DEFAULT NULL,
  `aktualizacja` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  `data` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  `ppc` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  `ppd` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  `pk` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL
) 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 (IMG:style_emoticons/default/wink.gif)

[Tomplus]

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...

[Nidan23]

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.

[SmokAnalog]

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?

[Tomplus]

@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.

[Nidan23]

@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 
  $sql = "SELECT PierwszePojawnie FROM 1";
  $conn->query('SET NAMES utf8');
$conn->query('SET CHARACTER_SET utf8_unicode_ci');
$result = $conn->query($sql);
 
if ($result->num_rows > 0) {
 blablabla
}
  else {$sql = "SELECT PierwszePojawnie FROM tabela2";
  $conn->query('SET NAMES utf8');
$conn->query('SET CHARACTER_SET utf8_unicode_ci');
$result = $conn->query($sql);
if ($result->num_rows > 0) {
 blablabla
}
}
[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)

[Tomplus]

Lepsze jest rozwiążanie:

[SQL] pobierz, plaintext 
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.

[Nidan23]

@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 
CREATE TABLE IF NOT EXISTS `klanplayers` (
  `miejsce` int(11) DEFAULT NULL,
  `tag` varchar(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  `nick` varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
  `ranga` varchar(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  `aktualizacja` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  `data` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  `ppc` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  `ppd` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  `ak` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
  `cb` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
 
CREATE TABLE IF NOT EXISTS `klandata` (
  `miejsce` int(11) DEFAULT NULL,
  `liga` varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
  `poziom` int(11) DEFAULT NULL,
  `tag` varchar(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  `nick` varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
  `donated` int(11) DEFAULT NULL,
  `sdonated` int(11) NOT NULL,
  `rdonated` int(11) DEFAULT NULL,
  `received` int(11) DEFAULT NULL,
  `roznica` int(11) DEFAULT NULL,
  `puchary` int(11) DEFAULT NULL,
  `warstars` int(11) DEFAULT NULL,
  `swarstars` int(11) DEFAULT NULL,
  `rwarstars` int(11) DEFAULT NULL,
  `gamedon` int(22) DEFAULT NULL,
  `awin` int(11) DEFAULT NULL,
  `dwin` int(11) DEFAULT NULL,
  `th` int(3) DEFAULT NULL,
  `elixir` int(22) DEFAULT NULL,
  `selixir` int(22) DEFAULT NULL,
  `uelixir` int(22) DEFAULT NULL,
  `gold` int(22) DEFAULT NULL,
  `sgold` int(22) DEFAULT NULL,
  `ugold` int(22) DEFAULT NULL,
  `dark` int(22) DEFAULT NULL,
  `sdark` int(22) DEFAULT NULL,
  `udark` int(22) DEFAULT NULL,
  `cwls` int(11) DEFAULT NULL,
  `scwl` int(11) DEFAULT NULL,
  `rcwl` int(11) DEFAULT NULL,
  `cg` int(11) DEFAULT NULL,
  `scg` int(11) DEFAULT NULL,
  `rcg` int(11) DEFAULT NULL,
  `cc` int(2) DEFAULT NULL,
  `gstar` int(4) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
[SQL] pobierz, plaintext 

[Tomplus]

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'?



Ten post edytował Tomplus 1.07.2019, 05:34:56

[Nidan23]

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

[Tomplus]

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.

[com]

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 (IMG:style_emoticons/default/wink.gif)

[Tomplus]

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.

[com]

no tak, masz rację (IMG:style_emoticons/default/wink.gif)

[Nidan23]

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.

Ten post edytował Nidan23 2.07.2019, 10:36:42

[Tomplus]

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
...

[Nidan23]

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...

Ten post edytował Nidan23 2.07.2019, 11:13:19

[Tomplus]

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ń (IMG:style_emoticons/default/smile.gif)

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