Wpis z mikrobloga

Mam takie głupie pytanie z baz danych. Mam listę produktów, ale klienci kupują po kilka. Produkty mam oddzielnie żeby łatwo śledzić trendy(nie mam opcji w stylu produkt1+produkt2). No i nie wiem jak to zorgarnizować przy transakcji. Widzę opcję robienia kilku wierszy jednej transakcji tylko z różnymi produktami co jest średnio wygodne albo zrobienie kolumn dla każdego produktu i wybór dla transakcji T/N. Czy ma ktoś ludzki sposób żeby to ogarnąć? Nie wiem jak tagować, bo nie jestem specem od baz.
#bazydanych #db
  • 11
@xDrope: Tabela pośrednia z transakcjami kupna skoro masz relację wiele do wielu.
Taka tabela będzie składać się co najmniej z idTransakcji, idKlienta, idPrzedmiotu. IdTransakcji generujesz w tabelce z boku zawierającej identyfikator i jakieś szczegóły typu data etc.

Generowanie kolejnych kolumn to zła droga.
@ludzik: czyli robię 2 tabele transakcje i w pierwszej mam to rozpisane transakcje na zakupy pojedynczych produktów, a druga tabela (to już chyba kwerenda będzie) będzie scalała 1 transakcję w 1 rekord z odnośnikiem do tabeli pierwszej?
@xDrope: Nie jestem pewien czy się rozumiemy.
TransakcjeSzcz: id int, data datetime i co tam byś jeszcze chciał
Transakcje: idTransakcji int, idKlienta int, idProduktu int tu będziesz miał jeden wiersz na jeden zakup i id transakcji obejmuje Ci jeden zakup dokonany przez klienta
@ludzik: dokładnie :) dzięki. Jeszcze pytanie czy da się to po ludzku w formularzu ustalić żeby np. zaznaczać kilka produktów i automatycznie robiło się kilka rekordów? Przyznam, że jestem zielony z formularzami i makrami, więc jak masz jakieś fajne źródło wiedzy to chętnie przygarnę, bo wujek google na tak szczegółowe pytania nie odpowiada ;_;
@xDrope: Od strony frontendu to ciężko mi się wypowiedzieć. Inna rzecz, że nie podałeś w czym to zrobione. Ale od strony baz, to najlepiej zrobić procedurę składowaną która zrobi rekordy dla danej transakcji.
@ludzik Access, bez fajerwerków. Teoretycznie bazę mógłbym robić w czymś innym, ale zupełnie się w tym gubię. W czym bazę w czym front, który niestety jest potrzebny.
@xDrope: Wiele zależy od potrzeb. Jeśli to ma ewoluować to Access długo nie ujedzie. To aplikacja dla sprzedawcy czy dla klienta? Bo jak Wam sypnie klientami to nie wiem czy to się nie udusi ;) Jeśli to pracownik ma wklepywać to spoko, bo pewnie nie będzie wielu userów działać naraz.
@ludzik: To ma być dla nas baza transakcji, kij wie jak duża i jak szybko się zrobi D:. Czyli dla sprzedawcy. Używać będzie kilku userów ale prawdopodobnie bez synchronizacji, czyli przy backupach będzie nie tyle mergowanie takich samych tabel, a robienie z kilku jednej kwerendy. Wbrew pozorom w mojej sytuacji będzie to mniej problematyczne rozwiązanie niż serwer/chmura.
@xDrope: No jasne. Do niewielkich zastosowań da radę. Ale poczytaj może gdzie są limity takiej bazy accessowej i ewentualnie przygotuj się na przesiadkę w perspektywie kilku lat. U siebie akurat operuję na dużych bazach, choć nie mam wielu userów, więc jestem wrażliwy na punkcie optymalizacji ;)