Zapytanie - SELECT * - bez konkretnych kolumn

0

W swojej bazie posiadam tabelę, której struktura zmienia się w sposób dynamiczny - zależny od użytkownika (administratora systemu).
Zawsze jednak w tej strukturze istnieją 3 pozycje, które są stałe
id | id_product | id_lang

Dla lepszego zobrazowania tego problemu rozważmy tę tabelę zmodyfikowaną przez użytkownika (administratora systemu). Tak więc oprócz powyższych pól mamy nowe (mogą one być dowolne/dowolnych typów).
id | id_product | id_lang | price | width | height | capacity

Czy istnieje sposób pobrania wszystkich kolumn - nie znając ich nazw - z wyłączeniem tych 3 stałych?
Coś jak SELECT nazwa_tabeli.* FROM nazwa_tabeli ale bez 3 pierwszych pól.

3

nie ma czegoś takiego jak SELECT * - (id, ...) FROM .... Możesz to zrobić pobierając wcześniej listę kolumn i sklejając zapytanie. Ale czy nie pobieranie trzech kolumn jest warte takiej zabawy?

9

Po pierwsze - uściślijmy Twój opis - masz tabelę której ilość kolumn zmienia się dynamicznie? Jeśli tak masz - to jest to źle zaprojektowana baza.
Po drugie - próbowałeś z aliasami? Bo jeśli nie odróżniasz jednego ID od drugiego - to zrób aliasy i starczy

SELECT *, a.id AS article_id, u.id AS user_id
FROM article AS a
LEFT JOIN `user` AS u ON a.author_id = u.id

Wtedy zwykłe ID możesz olać i użyjesz tego które Ci jest potrzebne

3

A jakbyś spróbowała podziałać z funkcją show_colmns? https://dev.mysql.com/doc/refman/8.0/en/show-columns.html
Mogłabyś opakować to w jakiejś procedurze, albo funkcji i pokombinować z przypisywaniem tych kolumn w select.
Tak sobie myślę.

@yarel, @Marcin.Miga Wy macie większe doświadczenie z mysql.

4
SELECT * FROM information_schema.columns WHERE TABLE_NAME='...' AND TABLE_SCHEMA='...'
/*dla pewności*/
ORDER BY ordinal_position

Powinno działać na każdej bazie.

2

Dla uzupełnienia podejścia do rozwiązania problemu.

Jeśli aplikacja generuje zapytania na zasadzie select * from foo f, to ta sama aplikacja może skorzystać z API connectora bazodanowego.

Nie wiem z jakiej technologii autor korzysta, więc poglądowo parę randomowych linków z internetów (pobieżnie przejrzałem i zawierają to co trzeba):

Hasło do wyszukiwania: "result set metadata"

0

tutaj nie chodzi o konkretne produkty, a konkretne strony. To taki mój "bazowy" system CMS, który ma być "uniwersalny". Tak więc mogę mieć stronę produktową z autami gdzie mam pojemność, rodzaj_nadwozia, rocznik itp oraz mogę mieć stronę produktową z zabawkami - tutaj akurat rodzaj_nadwozia w żaden sposób nie pasuje :) Od razu zaznaczę - jest to silnik na moje małe projekty (głównie wizytówki). Jeśli mam coś większego to baza jest budowana od podstaw - żeby ktoś się nie czepiał że na gotowcu można postawić wszystko, a później wydajność kuleje. — NewUser2k13 dziś, 10:17

Jest taki mniej czy bardziej oficjalny wzorzec, zapomniałem angielskiej nazwy, nazwę go dynamicznym rekordem, gdzie

  • rozbudowa danych jest pionie w specjalnej tabeli (ze stałą, niewielką ilością kolumn)
  • gdzieś obok, w sąsiedniej tabeli są definicje "dynamicznych kolumn" z podziałem na tabele macierzyste
  • prosta warstwa obiektowa, która to integruje (zapewniam, nie zabije wydajności)

Duża ilość pełniokrwistych ERP, CRM to używa. Nikt rozsądny nie da prawa alterowania tabel szeregowemu użytkownikowi, plus nie wiadomo jak z indeksami itd...

Właśnie schemat by się przydał, a jeśli masz kolumny z dynamicznymi typami danych to możesz zrobić trochę inne podejście ale to musiała bym mieć pół godzinki żeby Ci to rozpisać. — @kate87 dziś, 12:51

jestem zaciekawiony, o czym myślisz

2

https://stackoverflow.com/questions/9122/select-all-columns-except-one-in-mysql

Jak dobrze poczytasz, to będzie nawet jak to zrobić w PHP.

Jakby jednak nie myśleć nad rozwiazaniem, to "pozbycie" się kolumn z zapytania polega na wypisaniu wszystkich pozostałych, z * nie przejdzie

3

Jak te atrybuty nie będą mieć dużej ilości to czemu nie EAV? Jeśli masz np. 3 różne kolumny (jak podajesz) , to możesz zrobić prostą tabelę typu 'Product' czy coś tam i zamiast kolumn X,Y,Z
Dać kolumn 'key', 'value', 'product_id'; No i np Twoje auto będzie miało klucz 'engine' - value '1.8', klucz 'body' - value 'hatchback'. itd.
Wiem, wiem, można tak zabić bazę ale, dla 3 czy 5 atrybutów?
Panie i Panowie od baz?

1

https://i.ibb.co/Lxn0XnG/Bez-nazwy-1.jpg Pola oznaczone czerwoną ramką są dynamiczne. Nie znam ich nazw i typów gry tworzę zapytania - co więcej admin może dodać nowe/edytować istniejące. Robiąc SELECT product., product_description., product_feature.* FROM otrzymuję 3 pola o takiej samej nazwie id . Stąd też pytanie czy mogę pobrać wszystkie pola ale bez id, id_product, id_lang z tabeli ostatniej. Z drugiej tabeli mogę, bo znam nazwy kolumn i one się nie zmieniają. Zamiast product_description.* daje product_description.nazwa_pola itp.

No i to jest błąd natury projektowej :) - zastanawiałeś się co stanie się z danymi, gdy masz np wysokosc i admin chce tam ustawic wymiar w centymetrach, a w innym produkcie w metrach? Jeśli admin ma możliwość edycji kolumn w tabeli - to co sie stanie z danymi gdy zmieni typ danych np z float na integer? Albo cenę która zechce podać wraz z walutą? Idąc dalej... co sie stanie jak zedytuje kolumne i zmieni jej typ na varchar(2) - co stanie sie z reszta danych w bazie?

Uwierz mi, albo poszukaj w google - że oddawanie nawet w ręce administratora możliwości edycji kolumn w tabeli w interfejsie usera spowoduje więcej szkód niż pożytku. Zobacz jak jest zrobiona baza w wordpressie - masz tam termy i taxonomie i tam jest to zrobione dobrze i nikt dynamicznie tabel nie edytuje. Dodam, że na wordpressie stawiane są nawet sklepy internetowe i nie ma tam z tym problemu, a każdy produkt moze być opisywany całym szeregiem różnych parametrów np w zależności od kategorii produktu.

1

Chodzi mi po głowie rozwiązanie podobne do tego które zastosowałam w ostatnim projekcie. Mianowicie miałam ankietę która ma x pytań, pytania mogą się zmieniać w dodatku każda zmiana to musiała by być nowa kolumna w tabeli odpowiedzi x3 lub x4 (odpowiedź, opis i coś tam jeszcze) Potem te kolumny musielibyśmy w jakiś sposób pivotować do raportów, ale jak jeśli mam ogromną tabelę gdzie za każdym razem pytanie i odpowiedź to nowe 4 kolumny, dodatkowo mix typów danych. Po przepaleniu miesiąca na standardowe podejście(bo brak analizy, bo nie dogadane z klientem, bo jakieś wyciąganie królika z kapelusza) usiedliśmy w zespole i przegadaliśmy temat. Wyszło nam że podejdziemy do tematu niestandardowo, ale tak żeby ułatwić sobie robotę.

Otóż stworzyliśmy tabelę pytania w której było id, treść pytania, typ danych (varchar, date, int). join do tabeli odpowiedzi gdzie było pole pytanie_id i 6 pól odpowiedzi (odpowiedz_varchar1, odpowiedz_varchar2, ... _int, _int2, _date1, _date2) i jeszcze coś tam typu dowiązania do innych tabel. Dało nam to ogromną tabelę odpowiedzi ale wzdłuż nie wszerz i bardzo ułatwiło raporty.

Ty możesz u siebie zrobić taką tabelkę która będzie mieć kolumny i typy danych do nich, a w drugiej tabelce możesz trzymać odpowiedzi dodatkowo 3-4 pola z najpopularniejszymi typami danych typu typ_varchar, typ_int, typ_date... Obsłuż to na backendzie w sposób taki że wybieraj kolumnę z tabeli kolumn i w zależności od deklaracji typu wstawiaj dane do kolumny od tego typu w tabelce odpowiedzi.

W tym momencie nie interesuje Cię ile "kolumn" będzie dodane i jaki będą mieć typ, robisz swoje, a tabela kolumn i tabela odpowiedzi będzie łatwiejsza do raportów czy czegokolwiek innego.

1 użytkowników online, w tym zalogowanych: 0, gości: 1