Visualizzazione dei risultati da 1 a 8 su 8

Discussione: Console File di Testo

  1. #1

    Console File di Testo

    GoodWeb
    Sto realizzando una mini console che mi permetta di gestire un sito web di medie dimensioni.
    Nonostante sono consapevole che l'utilizzo di MySQL o altro data base relazionale sia il meglio, ho voluto comunque sviluppare il tutto basandomi su uno pseudo data base "FlatFile".

    Ora mi trovo ad un bivio .... sto cercando di capire cosa sia meglio fare, premetto che non sono un programmatore, ma parlo in qualità di autodidatta.
    Mi spiego ....

    Ho diverse tabelle (un file di testo per ogni categoria: es. grafica, internet, sicurezza, ...) e al loro interno gestisco le informazioni come array
    Codice PHP:
    $product_develop = array
        
    => array( 'subcat'        => "Database",
                    
    'url_file'        => "database.php",
                    
    'name'            => "DBDesigner 4",
                    
    'link'            => "http://www.fabforce.net/dbdesigner4/",
                    
    'desc'            => "[b]DBDesigner[/b] è un programma .............",
                    
    'wiki'            => "http://it.wikipedia.org/wiki/Base_dati",
                    
    'keysoft'        => array ("DBDesigner""DBDesigner data base""Database Designer"), 
    Con un ciclo "foreach" gestisco e manipolo le varie info.

    Un file "config" preimposta le diverse tabelle e le inizializza
    Codice PHP:
    /** DB CatDevelop            **/  $DBsubdevelop "db_cat_develop.php";
    /** DB Cat Include            **/  include_once ($Path.$DBsubdevelop); 
    Il problema:
    a) io inizializzo TUTTE le tabelle dal file config, anche se non necessarie in quel momento.
    Mi chiedevo se questo possa influire sulla resa e prestazioni del sito e di conseguenza sull'utilizzo delle risorse del computer.

    b) ho visto in rete diverse librerie / classi per la gestione dei file di testo come data base, in alcuni casi ho notato che gli stessi richiamano la funzione e passano i diversi record in modo sequenziale nell'array filed[0], filed[1], filed[2], ...
    Viceversa io apro una chiamata al data base con il nome riportato nel file config ($DBsubdevelop), anche se poi utilizzo lo stesso script di lettura per tutte le tabelle.
    Mi chiedevo se anche questo comporti un utilizzo sbagliato o maggiore delle risorse del PC.

    Spero di essere stato chiaro, in caso contrario chiedete e vi sarà dato.
    Se qualche d'uno vuole collaborare è ben accetto.....

    Grazie a tutti
    olGerva | Internet: la libertà di scrivere porta al sapere di molti
    http://www.slypage.com - http://www.wire-net.it

  2. #2

    Re: Console File di Testo

    Originariamente inviato da gervaweb
    a) io inizializzo TUTTE le tabelle dal file config, anche se non necessarie in quel momento.
    Mi chiedevo se questo possa influire sulla resa e prestazioni del sito e di conseguenza sull'utilizzo delle risorse del computer.
    IMHO è un dubbio inutile. Lavorare con un flat file è talmente poco performante che una valutazione del genere ha poco senso.

    Se voi lavorare su file, utilizza SQLite che almeno offre un supporto base per l'SQL. Altrimenti rischi che qualsiasi applicazione progetti per il tuo flat file, dovrai riscriverla (o rivederla pesantemente) per passarla su un'altro database, più performante.

  3. #3
    GoodWeb
    Grazie per il suggerimento, non sapevo di questo SQLite. Sicuramente farò delle prove .... anche se questi due punti mi lasciano un pochino perplesso:

    - SQLite raggiunge le migliori performance quando la quantità di dati salvati viene distribuita rispettando un limite di 230 byte per singola riga.
    In questo caso io con il FlatFile ho superato abbondantemente inserendo testi, riferimenti, key, etc. nell'array del mio FF la cosa e mi sembra funga benino ....

    - Da alcuni benchmark sembra che in questo ruolo SQLite sia in grado di sostenere circa 150 request al secondo: non si tratta affatto di un cattivo risultato ma, grazie al sistema dei file distinti, i file di testo gestiscono intorno a 400 request al secondo.
    E' vero che il mio progetto si rivolge a o siti medio piccoli, quindi 150 request sec. sicuramente possono bastare, ma nel caso un sito giri un minimo, magari 400 sono meglio. Senza contare il fatto che nel caso di SQLlite ho solo un file (problemi di accesso per più utenti) nel caso di FF potrei fare il look di un singolo file e lasciare gli altri liberi.

    In questi giorni ho scovato diverse soluzioni FF e una di queste mi ha incuriosito molto "chaozzDB" semplice e veloce.

    Il mio scopo è quello di far fungere il tutto sia su server Windows come Linux con PHP, che il tutto rimanga nella sola root del sito (script, page, db, js, etc.) così da essere facilmente trasportabile o farne il backup.
    Nessun vincolo al design (vedi smarty) quindi dei semplici include nelle zone definite dall'utente e un piccolo motore / console per quegli oggetti che gestiscono le informazioni.

    Allo stato attuale ho definiti molti oggetti lato frot-end gia funzionanti online, nel breve vedo di sistemare anche l'area admin, ma prima volevo sincerarmi su come ottenere il meglio dai FF.

    Lascio ai GRANDI i progetti GRANDI.

    Grazie e ciao
    olGerva | Internet: la libertà di scrivere porta al sapere di molti
    http://www.slypage.com - http://www.wire-net.it

  4. #4
    Originariamente inviato da gervaweb
    - Da alcuni benchmark sembra che in questo ruolo SQLite sia in grado di sostenere circa 150 request al secondo: non si tratta affatto di un cattivo risultato ma, grazie al sistema dei file distinti, i file di testo gestiscono intorno a 400 request al secondo.
    Richiese in lettura, in lettura/scrittura, con locking?
    E quale è il tempo medio di accesso nella ricerca?
    Il solo fatto di accettare la richiesta è irrilevante se poi l'indicizzazione dei dati è scarsa e richiede una ricerca sequenziale per essere portata a termine.

    Originariamente inviato da gervaweb
    Il mio scopo è quello di far fungere il tutto sia su server Windows come Linux con PHP, che il tutto rimanga nella sola root del sito (script, page, db, js, etc.) così da essere facilmente trasportabile o farne il backup.
    Nessun vincolo al design (vedi smarty) quindi dei semplici include nelle zone definite dall'utente e un piccolo motore / console per quegli oggetti che gestiscono le informazioni.
    IMHO il fatto di voler rendere leggermente più semplice il deploy di una applicazione non dovrebbe mai creare dei vincoli strutturali. Esistono innumerevoli tool per il backup (anche hot) delle web application, per non parlare del fatto che la maggior parte dei pannelli di amministrazione include procedure automatizza per backup e ripristino.

  5. #5
    GoodWeb
    In primo luogo sono a complimentarmi con te per il tuo sito e i diversi suggerimenti dati.
    Ma allo stesso modo ribadisco la mia affermazione: Lascio ai GRANDI i GRANDI progetti.

    Ora le tue affermazioni sono sicuramente fondate e certamente suggerimenti utili e professionali (viste e tue referenze), ma ti ricordo che il tuo interlocutore è un "autodidatta", quindi alcune sottili sfaccettature da me sono poco comprensibili.

    Richiese in lettura, in lettura/scrittura, con locking? ......
    In questo caso mi riprometto di testare SQlite come gia detto. Certamente l'utilizzo di un engine stabile è più interessante, ma allo stesso tempo mi chiedo quanti Hosting offrano questo servizio in modalità free..... Ribadisco il target della mia utenza e il rilasciare del mio progetto in modalità free e quindi presumibile verso una utenza "povera"

    IMHO il fatto di voler rendere leggermente più semplice il deploy di ....
    OK suggerimento valido e compreso, ma il io intento è la creazione di una "mini console" del tutto autonoma e senza vincoli di terze parti. Lo so che posso peccare di presunzione o forse meglio di testardaggine. Credo che il fatto di avere tutto sotto una root e senza necessità di plug-in, estensioni o altro sia una scelta valida.

    Dall'altro conto posso solo apprezzare il tuo intervento, viste le referenze e sicuramente la tua esperienza.
    olGerva | Internet: la libertà di scrivere porta al sapere di molti
    http://www.slypage.com - http://www.wire-net.it

  6. #6
    Originariamente inviato da gervaweb
    In questo caso mi riprometto di testare SQlite come gia detto. Certamente l'utilizzo di un engine stabile è più interessante, ma allo stesso tempo mi chiedo quanti Hosting offrano questo servizio in modalità free.....
    SQLite è disponibile nativamente in PHP 5. Praticamente tutti i provider che offrono PHP 5, offrono anche SQLite.

    Originariamente inviato da gervaweb
    Ribadisco il target della mia utenza e il rilasciare del mio progetto in modalità free e quindi presumibile verso una utenza "povera"
    "Povera" quanto? Ci sono fornitori di hosting professionale che per una ventina di euro offrono registrazione dominio, spazio e database MySQL.

    Originariamente inviato da gervaweb
    OK suggerimento valido e compreso, ma il io intento è la creazione di una "mini console" del tutto autonoma e senza vincoli di terze parti.
    IMHO dire che MySQL sia un vincolo di terze parti è al limite. Praticamente qualunque fornitore di hosting Linux offre MySQL.

    Originariamente inviato da gervaweb
    Lo so che posso peccare di presunzione o forse meglio di testardaggine. Credo che il fatto di avere tutto sotto una root e senza necessità di plug-in, estensioni o altro sia una scelta valida.
    IMHO è una scelta dettata dall'inesperienza. Rischi di avere più problemi di deploy causati dai privilegi di scrittura sui file che dall'utilizzo di MySQL.

  7. #7
    GoodWeb
    Dopo i tuoi preziosi suggerimenti, ho dedicato un minimo alla conoscenza e lettura di diversi post su SQlite.
    Sostanzialmente quasi tutti confermano l'utilità e l'efficacia dello stesso SQlite.

    Una cosa non ho percepito o capito, faccio un'esempio concreto:
    - ho un piccolo sito dove vengono recensiti "oggetti" (SQlite come DB su file unico dove risiedono diverse tabelle oltre a quella degli oggetti diciamo che ci metto le news).
    - ho un'area admin, dove il solo amministratore ha accesso (mi sembra una prerogativa di SQlite che vincola "look" la scrittura ad un solo utente) per la manutenzione
    tutto OK sin qui.....

    - offro la possibilità di commentare una recensione all'utente (guest), come la maggior parte dei blog o siti simili. Mi chiedo:
    1) posso creare e appoggiare i diversi commenti su altro file DB (aprendo una connect differente) così da evitare che operazioni di manutenzione del sito impediscano al visitatore di lasciare un commento. Certo nel caso ho due visitatori le cose cambiano, forse sarà necessario creare uno script d'appoggio temporaneo, ma questo solo dopo che avrò capito SQlite e il suo utilizzo.
    2) Nel caso il visitatore non sia "guest" ma necessiti di registrazione, cosa succede se io sto facendo manutenzione, il visitatore entra e un terzo si regsitra, quindi utilizzando lo stesso DB ma per tre operazioni distinte?
    3) Ne caso sul sito ho diversi, diciamo molti, visitatori come si comporta SQlite? La risposta potrebbe essere, come gia detto, "i comandi SQL sono standard e quindi portabile verso MySQL o altro DB in quel caso. Ma proprio per la mia volontà di mantenere il tutto nella root vorrei un parere a questa domanda.


    Grazie per la collaborazione
    olGerva | Internet: la libertà di scrivere porta al sapere di molti
    http://www.slypage.com - http://www.wire-net.it

  8. #8
    Per quanto riguarda l'utilizzo di più database, non la ritengo la scelta migliore. Non sono al corrente della possibilità di eseguire query tra più database ed in ogni caso una manutenzione "bloccante" dovrebbe essere comunque limitata a periodi molto brevi e/o molto distanziati nel tempo e/o in momenti di scarso utilizzo (es. ore notturne).

    Per il resto, ti rimando alla documentazione di SQLite:

    http://www.sqlite.org/lockingv3.html

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.