Pagina 1 di 3 1 2 3 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 26
  1. #1
    Utente di HTML.it L'avatar di misbo
    Registrato dal
    Nov 2001
    Messaggi
    282

    [Mysql]Progettazione db per molti reord

    Devo realizzare un database contenente più di 5 milioni di record-prodotti. Questi prodotti, divisi per categorie possono essere strutturati, secondo come l'ho pensata io, in due modi. Ho inserire tutti i record-prodotti in un unica tabella, oppure dividere i prodotti in tante tabelle secondo la categoria di appartenenza. Quale suluzione mi consigliate ? Havete altre proposte da farmi ?

    Grazie.

  2. #2
    Utente di HTML.it L'avatar di misbo
    Registrato dal
    Nov 2001
    Messaggi
    282
    up!

  3. #3
    Per me se dividi peggiori la situazione perchè poi sei sempre dietro che fai dei join con l'effetto di avere lo stesso numero di record che in più devono anche essere correlati.
    Ma sei sicuro di avere progettato correttamente il DB?

  4. #4
    Utente di HTML.it L'avatar di misbo
    Registrato dal
    Nov 2001
    Messaggi
    282
    Per adesso non ho realizzato ancora niente. Sto iniziando a pensare quale potrebbe essere la migliore soluzione per gestire una quantità di dati molto grande. Ho visto che mysql gestisce ottimamente fino a 50000 record. Quale soluzione quindi è la più conveniente in termini di prestazioni e scalabilità ?


    Ogni categoria di prodotto ha esigenze diverse in termini di catalogazione. Per esempio la categoria informatica necessita di titolo e descrizione prodotto, mentre la categoria Libri di Titolo ed autore. Quindi per ogni categoria campi diversi.
    Quale soluzione è più conveniente ?

  5. #5
    Utente di HTML.it L'avatar di misbo
    Registrato dal
    Nov 2001
    Messaggi
    282
    up

  6. #6
    Utente di HTML.it L'avatar di iox84
    Registrato dal
    May 2004
    Messaggi
    754

    consiglio

    La soluzione migliore dal mio punto di vista e' farsi un bel schema ER, studiare i volumi di traffico delle transazioni e vedere la soluzione ottimale, per quanto riguarda l'implementazione devi cercare un DBMS ottimale, non credo che mysql riesca a supportare performantemente il volume di traffico che devi gestire tu, cmq non ho mai provato a smanettare con grossi DB su mysql quindi mi potrei sbagliare.

    Posso dirti che ORACLE e' un ottimo DB (parlo per sentito dire) ma non so in che maniera venga gestito e se trovi qualche hosting...

  7. #7
    Ovviamente lo schema ER davanti a tutto e occhio anche al calcolo sui costi di mantenimento sui dati derivati.
    A parte questo che lo davo per ovvio credo che 50000 record oggi non siamo un problema per nessun DBMS.
    Vi basti sapere che ho in giro un DB Access che gestisce tabelle più grandi senza problemi su un Celeron 2000.

  8. #8
    ho provato mysql anche con 1 milione di record...
    mica si fa problemi per le migliaia..

  9. #9
    Utente di HTML.it L'avatar di misbo
    Registrato dal
    Nov 2001
    Messaggi
    282
    Ma la soluzione ha tabelle multiple per indicare l'entità prodotti, se cosi possiamo definirla, è proprio da buttare ?

    E' da poco che studio su questi argomenti. Quali sarebbero gli svantaggi portati nell'utilizzo di una struttura del genere ?

    forse penso che lo stesso google utilizzi una solozione simile.

    Io, nella mia semplicità, immagino la struttura di google in questo modo:

    tutte la pagine vengono indicizzate in tabelle simili in struttura.
    Le tabelle vengono identificate secondo una griglia simile alla battaglia navale. Ogni tabella ha il compito di immagazzinare particolari tipologie di dati, suddivisi per contenuto. Quando si effettua una ricerca non si esegue la query su tutte le tabelle, ma solo su quelle interessate. Una tabella principale identifica la tipologia di dati presenti nel database indicandomi su quale tabella effettuare la ricerca.

    Questo è quello che ho pensato e che vorrei realizzare.
    E' fattibile o ho sparato solo un mucchio di cavolate ?

  10. #10
    Utente di HTML.it L'avatar di iox84
    Registrato dal
    May 2004
    Messaggi
    754
    Penso che lo svantaggio sia uno solo: il fatto che per estrarre i dati devi fare join e affini, comunque preferisco il frazionamento quando e' possibile e concettualmente corretto, questo e' un parere personale...

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.