Visualizzazione dei risultati da 1 a 4 su 4
  1. #1

    Campo ID: piccola analisi sul tipo di dato da utilizzare

    Ciao a tutti
    vi scrivo per cercare di trovare chiarezza ad un dubbio venutomi in fase di analisi per la creazione di un DB, che riguarda più specificatamente il famigerato campo "ID".

    Nelle mie poche esperienze lavorative, e sopratutto in ambito scolastico, ho sempre impiegato un ID di tipo intero (o suo analogo) con successo: questo limitatamente a progetto di piccole/medie dimensioni. Il progetto al quale sto lavorando ora implica la necessità di memorizzazione di una grandissima quantità di tuple, e mi sono domandato "basterà un indice numerico 'classico' "?

    Navigando sul web ci saremo resi tutti conto di come in siti web quali youtube.com o i più noti social network dei valori siano passati sottoforma di lettere e numeri. Secondo voi sono campi ID di tipo stringa elaborati come sistemi numerici in base 36? Questo, pensavo, sarebbe una soluzione valida ad esempio all'indicizzazione in un archivio dei video di youtube (che sono un'infinità ed aumentano vertiginosamente in pochi minuti).

    É forse questo un tipo di soluzione da prendere in considerazione? Ovvio che delle operazioni su un campo INT o suo derivato sarebbero molto più rapide rispetto ad una mera stringa (perchè alla fin fine così andrebbe memorizzato il dato, pena altrimenti la conversione in INT e l'inutilità di tutta la procedura). Ma potrebbe essere una soluzione "concreta" al problema di spazio di indicizzazione in un archivio quando si ha comunque la necessità di non eliminare i contenuti a distanza di tempo?

    Vi ringrazio in anticipo, e vi prego di perdonarmi se non sono stato un campione di chiarezza.
    A voi

  2. #2
    quantifica il concetto di " una grandissima quantità di tuple", grazie

  3. #3
    Originariamente inviato da optime
    quantifica il concetto di " una grandissima quantità di tuple", grazie
    Poniamo il caso di youtube ad esempio. La banca dati deve essere in grado di accogliere un numero di video altissimo ogni giorno. Non voglio dire che questo sia il mio caso, ne che sia uno analogo a quello di facebook. Avevo in mente la progettazione di un nuovo social network, e sicuramente una delle prime cose da tenere in considerazione nell'analisi è (qualora il progetto funzionasse, ovvio) la necessità di memorizzare una quantità notevole di dati.

    Quantificare al momento mi è impossibile, purtroppo... non ho fatto una stima. Considera comunque un qualcosa di analogo a facebook ma con un numero di "contributi" degli utenti inferiore. Già comunque il pensare ad una tabella "commenti" o "mi piace" mi fa pensare ad un qualcosa al quale un semplice INT non può sopperire.

    Ovvio che, comunque, anche un sistema in base 36 avrebbe i suoi limiti, ma capisci che se si unisce la lunghezza di un campo stringa (che se non erro è di 255 char) alle 36 combinazioni possibili di lettere e numeri, ti esce un qualcosa come 36^255 combinazioni differenti. Il discorso è ancora ampliabile se, come nel caso di youtube (sottolineo che IPOTIZZO siano indici quelli contenuti nel link di tipo youtube.com/watch?v=...) ci mettiamo in mezzo anche dei simboli.

  4. #4
    piedi per terra. se il tuo social network avrà mai il successo di facebook, te ne strafregherai del dimensionamento di un indice

    quindi inizia col pensare "correttamente". cosa devi indicizzare? i vari "mi piace"? i messaggi?

    se parliamo di mysql, ad esempio, un INT unsigned può arrivare a 4294967295 (cfr http://dev.mysql.com/doc/refman/5.0/...ric-types.html). Metti tu i puntini separatori delle migliaia e facci sapere se ti può bastare...


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.