Visualizzazione dei risultati da 1 a 10 su 10
  1. #1
    Utente di HTML.it
    Registrato dal
    Jul 2005
    Messaggi
    642

    ASP: scelta tra pagina singola da lcontenuto personalizzato o tante pagine

    Salve mi trovo a dover fare questa scielta:
    creare una pagina singola il cui contenuto varia a seconda delle richieste dell'utente optate nel database.

    Cosa potrebbe accadere a quella pagina se gli utenti fossero mille ed ognuno richiedesse un proprio contenuto?

    Ci potrebbero essere problemi?.

    La seconda scielta e' quella di far generare dal sistema tante pagine a seconda delle richieste e quindi non memorizzare i dati nel database, ma semplicemente richiamare a seconda della richiesta la giusta pagina generata dal sistema.

    tra i vantaggi c'e' il fatto che posso superare il vincolo di 8000 caratteri per records offerta da MSsql

  2. #2
    Moderatore di ASP e MS Server L'avatar di Roby_72
    Registrato dal
    Aug 2001
    Messaggi
    19,563
    Quella del vincolo mi è abbastanza nuova... VVoVe:
    A parte questo la scelta è funzione di quello che devi fare per creare le pagine ma soprattutto per aggiornarle.
    Se non hai bisogno di fare manutenzione ai contenuti può andare bene una (tante) pagine statiche.
    I concentti di dinamicità però mirano a superare queste limitazioni...

    Roby

  3. #3
    Moderatore di ASP e MS Server L'avatar di Roby_72
    Registrato dal
    Aug 2001
    Messaggi
    19,563
    Insomma dipende da quello che devi fare.

    Roby

  4. #4
    Roby c'è l'eco sul forum.

    Tornando in topic, dico la mia.
    Ho una pagina di un mio web che a seconda le scelta dell'utente visualizza o meno determinate sezioni.
    Se vi dico quante righe di codice è, rabbrividite (penso), comunque son circa 13.000 righe!!!! VVoVe:

    Ad ogni modo mi son permesso di fare ciò, considerando il fatto che è una pagina sulla quale, al massimo possono andare 2 utenti: me e l'altro webmaster, è una pagina di amministrazione.

    Per cui dipende molto anche dagli accessi della pagina.
    Se è una pagina aperta a tutti gli utenti, non arrivare ai miei livelli, tanto per darti una dritta!
    Provare paura per un qualcosa che ti possa capitare nel futuro non ti evita quell'evento,ti fa soltanto vivere un presente sbagliato!

  5. #5
    Utente di HTML.it
    Registrato dal
    Jul 2005
    Messaggi
    642
    Salve, grazie per le risposte, un p odi chiarimenti.
    In MSsql ogni recordset puo contenere al massimo 8000 caratteri ci osignifica che far riempire quel recordset ad un utente e' abbastanza limitante ammeno che io non pon ga la condizione se il testo inserito è > di 8000 allora cambia recordset.

    fatta questa precisazione ora vedo di chiarire meglio la mia problematica:
    supponiamo che io abbia una pagina che mostri in seguito alla richiesta del utente registrato un contenuto piuttosto che un altro.

    Il mio dubbio era questo:
    ese gli utenti iniziano a diventare 1000 1000000 , cosa potrebbe accadere a sta povera pagina e a sto povero database che si trova adover esaminare 100000 richieste contemporaneamente?.

    ecco allora che mi era venuta questa idea: se l'utente vuole creare la pagina allora fagliela creare chiamandola nomeutente+dATA ATTUALE.

    SE L'UTENTE RICHIEDE LA PAGINA RICHIAMA LA PAGINA RICHIESTA.

    questo se da un lato riempire bbe il dominio di file dall'altro potrebbe diminuire i tempi di accesso che ne pensate cosa m iconsigliate

  6. #6
    Moderatore di ASP e MS Server L'avatar di Roby_72
    Registrato dal
    Aug 2001
    Messaggi
    19,563
    Centomila richieste contemporanee non ce l'ha neppure la Microsoft.
    Se quelli sono gli obiettivi devi strutturare il db in maniera estremamente performante, lavorando con le store procedure per ogni query che ti serve, un server dedicato, un processore potente, ecc...
    Una pagina può essere richiesta da 100000 utenti ma sarebbe la stessa cosa nel caso fossero richieste 100000 pagine ma tutte agissero, come la prima, sullo stesso db.
    Detto questo, una query che estragga più di 8000 caratteri la vedo abbastanza inutile per un utente medio...
    Quale tipo di informazione può essere così enorme? E che tipo di informazione sarebbe?
    Paginazioni o altri metodi ti potrebbero consentire di limitare la visualizzazione a quello che realmente occorre.

    Roby

  7. #7
    Utente di HTML.it
    Registrato dal
    Jul 2005
    Messaggi
    642
    Quindi tu mi consigli il database e sia anche se lacosa mi lascia perplesso per due motivi:

    1 se questa e' una pagina che mostra contenuto in base ad una query via web trovo estremamente complicato riuscire a consigliare la pagina ad un amico poiche cliccandoci sopra il link risulterebbe vuota!!!!!

    2 le info da inserire sono molto lunghe ogni utente pubblica una pagina web per volta

  8. #8
    Moderatore di ASP e MS Server L'avatar di Roby_72
    Registrato dal
    Aug 2001
    Messaggi
    19,563
    Non ti sto consigliando dipende da quello che devi fare.
    Se i contenuti sono statici fai centinaia di pagine...
    Se sono soggette a modifiche non vedo molte alternative.

    Roby

  9. #9
    Utente di HTML.it
    Registrato dal
    Jul 2005
    Messaggi
    642
    grandissimo!!! mi hai aperto la mente
    come sempre la verita' e' nel mezzo, mettero le parti dinamiche soggette a variazioni in un database e la parte statica e piu' grande in file singoli.
    credo di aver risolto alche il problema del consiglia la pagina ad un amico ho pensato a questo:se lutente vuole consigliare la pagina: allora crea i lsequente link http://www.nome.it?query1 query 2 ecc,
    quando il destinatario clicchera su questo link verra reindirizzato alla pagina delle query analizer che in base alle stringhe contenute nel link creera la pagina che si voleva consigliare, be ragazzi buon lavoro a tutti questa sera si programma fino all'alba

  10. #10

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.