Newsgroup: it.comp.www.php
Titolo: Utilita' e limiti di PHP

Salve a tutti,
 da un po' di tempo ho iniziato a programmare in php,
spinto sia da un'insana curiosita' verso tutto cio' che
si puo' programmare :) sia dalla semplicita' e somiglianza
con il C.
  Benche' non programmi da molto tempo, sono riuscito a
fare alcune cose carine (per me, per voi saranno sicuramente
banalita' :D) e percio' ho deciso di iniziare ad approfondirlo
di piu'.
  La domanda che vorrei porre a chi usa questo linguaggio
da piu' tempo di me e': quali sono i limiti di questo linguaggio?
Cioe', cosa non si puo' fare in PHP+MySql (accoppiata che sto'
imparando ad amare/odiare) o che si puo' fare solo facendo
i salti mortali? In quali applicazioni invece e' praticamente un must?
Bow-wow
Killer

 ha scritto nel messaggio
news:pMG08.1839$Gy1....@news1.tin.it...



Inoltre, puoi usare PHP come linguaggio di Shell
(sostituendo il buon vecchio Perl). Interessante anche
l'interfacciamento con le librerie GTK di gnome e(parlando
sempre di web) con Flash.
Le features di PHP sono infinite (XML,Java,oggetti COM
etc.).
Basterebbe dare uno sguardo alla lista di funzioni dal
manuale di PHP (
www.php.net
) .
-- 
WEbdOM webmaster di
Metronic.It mobile phone philosophy
www.gadgetpoint.it
 serigrafia on line

 da piu' tempo di me e': quali sono i limiti di questo linguaggio?
Il linguaggio (essendo un linguaggio di programmazione strutturato) non ha
limiti (Puoi creare una macchina Turing ;-)...
per l'utilizzo reale dividerei forse:
Ottimo: Internet Web server, Applicazioni intranet Client-Server (Client
independent), script di produzione.
Con fatica: Applicazioni standalone (incluso Applicazioni distribuite con
DVD, CD-Rom).
Inefficiente: calcolo numerico (Analisi grafica, suono, simulazioni,
Loganalysis ecc.)
Offlimit: Applicazioni realtime (, sistemi operativi, sistemi embedded (con
fatica?).

 DVD, CD-Rom).
:) sarei interessato ti spieghi meglio?
posso far girare le pagine php in un cd? chi le interpreta?

 wrote in message
news:a21203$svt$1...@news.panservice.it...

Leggi qui: 
http://www.dopoil.com/PHP-FAQ/faq.php?phpdacdrom

 ha scritto nel
messaggio news:5JU08.28922$aD.10...@twister2.libero.it...

Grazie mille

 Cioe', cosa non si puo' fare in PHP+MySql (accoppiata che sto'
MySQL attualmente non supporta: 
- integrità referenziale 
- transazioni
- chiamate SELECT annidate
- stored procedure
E quindi ne è sconsigliato l'utilizzo professionale, ad esempio, per 
grosse applicazioni di e-commerce.
La logica di MySQL è sempre stata quella di privilegiare la performance 
rispetto alle funzionalità. 
L'accoppiata PHP/MySQL è pertanto indicatissima per portali di fascia 
media, di scopo soprattutto divulgativo/informativo. E' un linguaggio 
molto semplice e la cui curva di apprendimento è sempre più in discesa.
A patto di fare molta pratica, però :)
bye

 bye
Personalmente vengo da Microsoft/ASP e devo dire che in un paio di settimane
di pratica sto già facendo il porting di alcune cose da ASP/Access a
PHP/mySQL.
Va tutto molto bene... l'unica cosa è che sento un pò la mancanza appunto di
integrità referenziale e transazioni in mySQL, cose che in un database
semplice come ad esempio Access ci sono e devo dire funzionano anche bene.
Spero che mySQL 4 sia pronto presto perchè hanno promesso che queste cose ci
saranno.
Ciao

saranno.
 Anche io ne ho senitto parlare, ma è un'azienda diversa
dalla Tcx che sta implementando la versione transazionale
(diciamo così) di MySQL. Spero la licenza sia sempre la
stessa e che non diventi un software commerciale.


 quanto MySQL però).
Access, a prescindere dai noti limiti per il suo uso sul web, supporta
l'integrità referenziale ed il cascading delete. Dunque, volendo propio
disquisire, il termine "relazionale" puo essere usato quando si parla di
Access, non lo stesso per MySQL che di "relazionale" non ha un bel niente.
Su Access le transaction non sono supportate internamente, ma possono essere
integrate. Ad esempio ColdFusion o Transaction server ti consentono di
usarle, cosa non possibile su MySQL (non saprei se per limiti dei driver
MyODBC o altro). Certamente poi, nel momento in cui ho bisogno di
transaction, Access non lo guardo neppure :-)
MySQL é solido come una roccia e veloce come un lampo (in lettura), per il
resto trovo che sia ampiamente sopravvalutato e lo ritengo l'anello debole
della catena Unix/Apache/PHP/MySQL.
Da tempo mi riprometto di cominciare ad usare PostgreSQL, purtroppo la mia
conoscenza di Linux é praticamente nulla (non si puó imparare tutto e tutto
in una volta), e la cosa mi risulta difficoltosa, inoltre trovare una ditta
di hosting con una buona reputazione e che supporti PostgreSQL e PHP non mi
sembra facilissimo, dunque continuo a rimandare e le cose complesse le
faccio su SQL Server (e ColdFusion).
Ovunque sento lodi sulla versione 7 di PostgreSQL, e vedo con piacere che
diverse case editrici hanno cominciato a dedicargli libri (New Riders, Wrox,
SAMS, adesso anche O'Reilly!). Per quanto sia peró triste dirlo, credo
bisogna ammettere che la mancanza di una versione per Windows, facilmente
installabile e che si possa usare almeno per test e sviluppo, sia uno dei
fattori che ne compromettono la popolaritá a scapito di MySQL il cui team é
decisamente riuscito ad attirare l'attenzione di tanti.
Massimo


Scusate la mia ingnoranza, ma cosa sono queste cose??
:-?

 :-?
Sei scusatissimo: nessuno di noi è nato imparato, nemmeno i ciccioni che
lavorano su Oracle ;-))
(1) Le "stored procedure" sono insiemi (set) di comandi SQL che vengono
memorizzati sul server. Il client, a quel punto, non deve inviare ogni volta
una stessa query perché può fare riferimento alla procedura immagazzinata
(stored) sul server, e tutto questo migliora la performance complessiva del
database. MySQL non supporta nemmeno i trigger, che sono delle stored
procedure che si attivano quando accade un evento specificato ("se cancello
A, cancella anche B C e D", tanto per fare un esempio veramente grezzo).
E' previsto che mySQL 4.1 supporti le stored procedure e i trigger.
(2) Le chiamate SELECT annidate (dette anche "subquery") sarebbero una cosa
molto utile: sono praticamente delle query inserite in una clausola WHERE.
Per esempio:
    SELECT * FROM tabella_cani WHERE id = (SELECT id from tabella_dobermann
WHERE nome = 'Fuffi');
Le subquery dovrebbero essere in arrivo: anzi, io direi di dare un'occhiata
al sito di mySQL per verificare lo stato di avanzamento dei lavori.
Il resto alla prossima puntata, perché adesso mi aspettano i maccheroni e,
scusate, "ubi maior minor cessat" (questa procedura, se vi interessa, ve la
traduco domani ;-))
_China

quanto MySQL perň).
No, pero' scala meglio. Sotto carico anche medio, per query non banali
(non SELECT * FROM users WHERE IP=192.168.1.224, per capirsi :-) ), se
la cava meglio PostgreSQL.
Leonardo

 E' previsto che mySQL 4.1 supporti le stored procedure e i trigger.
Già, un deciso passo in avanti, ma, a mio modesto avviso, l'utilità delle
stored procedure senza transaction è drasticamente ridimensionata...
Certo, posso incapsulare tante cose in una stored procedure per non esporre
la struttura del db all'applicazione (cosí posso cambiare la struttura del
db senza spaccare le applicazioni, solamente modificando la stored
procedure) e migliorare la sicurezza (do accesso solo alla stored procedure,
il resto niente). Peró quel di cui continuo a sentire la mancanza é la
possibilità di avere operazioni complesse insert/update/delete gestendo le
transaction all'interno del db, il tutto bello e impacchettato dentro una
stored procedure, a quel punto guarderei MySQL diversamente :-)
Lo so, lo so, dovrei cominciare a guardare Postgres... Ma devo anche
migliorare il mio T-SQL e muovere i primi passi con Java, una cosa alla
volta :-)
Massimo

 ha scritto nel messaggio
news:B86B9CC9.7426%rdicora...@inwind.it...
