Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 11

Discussione: Gestione campi utente

  1. #1
    Utente di HTML.it
    Registrato dal
    Jun 2008
    Messaggi
    1,317

    Gestione campi utente

    Chiedo a voi lumi su quale possa essere la soluzione "migliore".

    Nella mia applicazione non ho creato fields come "nome", "cognome" nella tabella utenti (quella si concentra solo con i dati che sono indispensabili per il corretto funzionamento dell'applicazione e che sono immutabili, ovvero non possono essere tolti o meno, come il campo email o password).

    Per gestire i campi aggiuntivi come, appunto "nome" e "cognome" mi consigliate di creare una tabella

    fields con i suoi relativi dati (nome, lunghezza massima, tipo[textarea, input, ...]) e poi users_field per assegnare ogni campo ad un utente

    o dovrei gestire il tutto con alter table ogni volta che aggiungo un campo e puttarlo nel gruppo users?

    Secondo voi? Penso sia pià "dispendioso" per l'applicazione modificare la tabella di migliaia di utenti ogni volta che aggiungo o meno un campo... o lo è di più estrarre più dati con una left/right join quando estraggo tutti i dati dell'utente che dovrà cercare anche tutti i fields aggiunti?

  2. #2
    dipende se le colonne restano fisse nel tempo, oppure se queste "proprietà" cambiano in continuazione

  3. #3
    Utente di HTML.it
    Registrato dal
    Jun 2008
    Messaggi
    1,317
    di quale colonne parli?

    Penso che una volta che l'admin abbia settato o eliminato i campi che vuole (tipo, nome, cognome, firma, skype) non li andrà a modificare poi così spesso...

    A differenza gli utenti li modificheranno con la stessa frequenza, sia che stiano in "users_field" o puttati con alter table

  4. #4
    campo=colonna - stiamo parlando di db...

  5. #5
    Utente di HTML.it
    Registrato dal
    Jun 2008
    Messaggi
    1,317
    Si ma la risposta è più o meno la stessa, una volta che l'admin ha settato i suoi campi aggiuntivi, non penso che li andrà a modificare poi così spesso...

  6. #6
    ugualmente, vale la mia prima risposta

  7. #7
    Utente di HTML.it
    Registrato dal
    Jun 2008
    Messaggi
    1,317
    ok, e quale è? alter table o fields?

  8. #8
    ma quale è cosa? hai letto la mia risposta? "dipende se le colonne restano fisse nel tempo, oppure se queste "proprietà" cambiano in continuazione"

    tu rispondi e io rispondo

  9. #9
    Utente di HTML.it
    Registrato dal
    Jun 2008
    Messaggi
    1,317
    si ma parli delle collone di "users" o di "users_fields" ?

    Immaginiamo che la tabella utenti è questa (cè poco da immaginare visto che ho fatot copia-incolla):
    CREATE TABLE users(
    user_id mediumint(8) unsigned NOT NULL auto_increment,
    user_nickname varchar(20) NOT NULL default '',
    user_password char(32) NOT NULL default '',
    user_salt char(10) NOT NULL default '',
    user_email varchar(80) NOT NULL default '',
    user_avatar tinytext NOT NULL default '',
    user_avatar_type enum('url', 'upload', 'gallery') NOT NULL default 'url',
    user_avatar_width varchar(3) NOT NULL default '',
    user_avatar_height varchar(3) NOT NULL default '',
    user_group tinyint(3) unsigned NOT NULL default '0',
    user_language char(2) NOT NULL default 'it',
    user_template tinyint(3) unsigned NOT NULL default '0',
    user_timezone enum('-12', '-11', '-10', '-9', '-8', '-7', '-6', '-5', '-4.5', '-4', '-3.5', '-3', '-2', '-1', '0', '+1', '+2', '+3', '+3.5', '+4', '+4.5', '+5', '+5.5', '+6', '+7', '+8', '+9', '+9.5', '+10', '+11', '+12') NOT NULL default '+1',
    user_hidden enum('0', '1') NOT NULL default '0',
    user_dst enum('0', '1', '2') NOT NULL default '0',
    user_last_action int(10) unsigned NOT NULL default '0',
    user_last_access int(10) unsigned NOT NULL default '0',
    user_reg_date int(10) unsigned NOT NULL default '0',
    user_ip varchar(50) NOT NULL default '',
    user_last_ip varchar(50) NOT NULL default '0',
    user_pms smallint(5) unsigned NOT NULL default '0',
    user_birthdate varchar(10) NOT NULL default '',
    user_posts int(10) unsigned NOT NULL default '0',
    user_subscriptions enum('0', '1', '2') NOT NULL default '0',
    user_hide_email enum('0', '1') NOT NULL default '0',
    user_receive_emails_admins enum('0', '1') NOT NULL default '1',
    user_receive_emails_users enum('0', '1') NOT NULL default '1',
    user_receive_pm_users enum('0', '1') NOT NULL default '1',
    user_pm_notify_email enum('0', '1') NOT NULL default '0',
    user_signature text NOT NULL default '',
    PRIMARY KEY (user_id)
    )ENGINE=MyISAM;

    E contiene solo i parametri che sono necessari per il corretto funzionamento del board (tipo non posso eliminare birthdate perchè se la registrazione richiede il COPPA non potrei utilizzarla).

    Ora l'amministratore del sito che tratta (per esempio) di counter strike vuole inventarsi il campo "Clan".

    Se l'applicazione viene gestita con alter table, quando l'amministratore creerà il campo eseguirò:
    ALTER TABLE users ADD clan [parametri scelti dall'amministratore, tipo lunghezza massima del campo]

    Altrimenti se gestistico il tutto via fields, e user_fields avrò due tabelle (che ho sviluppato ora):

    CREATE TABLE fields (
    field_id smallint(3) UNSIGNED NOT NULL auto_increment,
    field_type enum('input', 'textarea', 'select', 'radio', 'checkbox') NOT NULL default 'input',
    field_name varchar(100) NOT NULL default '',
    field_values text NOT NULL default '',
    field_desc varchar(100) NOT NULL default '',
    field_lenght smallint(5),
    field_active enum('0', '1') NOT NULL default '1',
    PRIMARY KEY (field_id)
    );



    CREATE TABLE user_fields (
    userfield_id int(10) UNSIGNED NOT NULL auto_increment,
    userfield_fid smallint(3) UNSIGNED NOT NULL default '0',
    userfield_uid mediumint(8) UNSIGNED NOT NULL default '0',
    userfield_value text NOT NULL default '',
    PRIMARY KEY (uf_id)
    );

    E quando l'amministratore inserirà il campo "clan" creerò:
    INSERT INTO fields (field_type, field_name, field_lenght) VALUES ('input', 'Clan', 100);


    Ora gli utenti del sito quando si registreranno acederanno al profilo, e se ho utilizzato alter table, modificheranno "clans":
    UPDATE users SET clans = 'Nome clan' WHEREa user_id = 'id utente';

    Mentre se la ho creata con fields aggiungero una riga su user_fields con il valore che è collegato:
    INSERT INTO user_fields (userfield_fid, userfield_uid, userfield_value) VALUES ('id field clan', 'id utente', 'nome del clan');

    Ora siccome non riesco a capire la tua domanda provo a risponderti con informazioni superflue:
    L'amministratore aggiungerà e/o modificherà spesso il campo "clan" o ne inserirà di altri? Non lo so, ma in linea di massima, non credo, aggiungerà 2-3 campi in più che gli servono per il forum e poi li lascerà stare...

    L'utente inserirà o modificherà spesso il campo clan? Non lo so, ma in linea di massima, lo farà solo poche volte o altre neanche inserirà il valore...

  10. #10
    continuo a non capire cosa vuoi sapere: se è una colonna "istituzionale" va nella tabella utenti; se è un valore che si aggiunge al volo, ogni tanto, se ti fa comodo ecc ecc, allora va nella tabella degli attributi utente (chiamali user fields o come ti pare). è ovvio che la seconda è più lenta ma più flessibile. è ovvio che la prima è più veloce ma più rigida. ma sono cose che ti sei già detto da solo. quindi, che vuoi sapere in più?

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.