"cyber_man" <cyber_man> ha scritto nel messaggio news:257635@...

Scusami Christian ma il tuo atteggiamento è inaccettabile.

?? aspe non frainterdermi non ho usato toni antipatici o peggio maleducati, leggi le emoticons

Ti ostini a far cadare dal cielo le verità che conosci e non spieghi tecnicamente il motivo che ti ha indotto ad usarle ad un ignorante come me.

ehm veramente non c'è nulla da spiegare nello standard ansi sql non è permesso usare order by
esattamente come a scuola di hanno spiegato che un quadrato ha 4 lati

Sarai sicuramente un bravo sviluppatore ma come docente non sei granchè :-D

diciamo che non faccio la sviluppatore, inoltre se l'alievo si ostina a voler dire che un quadrato ha 3 lati non c'è docente che ne ha colpa Come docente puoi fargli capire che quello lui chiama quadrato si chiama triangolo ma nulla di più

Stavo per scrivere "Mai usato TO 100 percent!" ma invece adesso mi accorgo che se in una view specifico un ordinamento allora TOP 100 PERCENT mi viene
aggiunto automaticamente.
Non SOLO! Ma "SELECT * FROM (SELECT * FROM A ORDER BY a.a1)" da l'eerore di
cui parlate!

Strano che non me ne sia mai accrto... Allora forse non sono tante le query
dove uso ORDER BY!

idem come sopra perchè vuoi fare un ordinamento di una subquery?? Che non è permesso nello standard ansi sql

PS visto che ti ostini a pensare che il problema è di mssql ti lascio questa lettura di interbase
http://bdn.borland.com/article/0,1410,30296,00.html

Vedi che stò imparando qualcosa ?

sei sulla buona strada :-D
vediamo anche il perchè non si può fare, sei daccordo con me che odinare una subquery creerebbe un doppio ordinamento?
Quindi ritorniamo al post di Luca

Grazie Maestro Grazie... Mi Mandi la fattura ? :-D

non sono così esoso mi accontento (per ora) di una birra

Deduco quindi che per presentare una VIEW in una pagina WEB tu, al fine anche solo dell'ordinamento, passi prima da una SP.

le view non si presentano si usano internamente alle stored procedure, allora vediamo di spiegare per bene cosa sono e soprattutto a cosa servono le viste.

Il risultato di una vista è una tabella dinamica pertanto la vista viene creata per semplificare la costruzione delle query.
Per maggiori info http://en.wikipedia.org/wiki/View_(database)

Allora deduco che se usi la SP, anche solo in alcuni casi, solo al fine dell'ordinamento sicuramente ti farebbe comodo che la VIEW potesse ritornare all'applicazione un set di dati ordinato.

allora è tutto al contrario, la vista è una tabella dinamica che ti permette di visualizzare i dati di 23 tabelle fisiche in modo semplice, pertanto la vista viene creata per velocizzare l'estrapolazione dei dati. Immagina di avere 3 tabelle fisiche (clienti, fatture, dettaglio fatture), crei 1 vista che ti restituisce i dati dalle varie tabelle.
La vista la userai per creare le seguenti stored procedure lista fatture clienti con ordinamento per ragione sociale, lista fatture clienti con ordinamento per data, ecc.
come vedi l'ordinamento sulla vista non serve a un beneamato l'unico ordinamento che ti servirà sarà nelle stored procedure.

Ma se non mi spieghi il motivo tecnico che spinge cotanti standard (ansi, mssql, oracle, db2, sybase, informix, ecc) a rendere "errato" come scrivi tu l'uso di ORDER BY io non lo capirò mai.

non sono standard ma sono diversi database server, e tutti non accettano order by nelle viste, esattamente come una figura con 4 lati uguali si chiama quadrato :-D

Tu dici che è "errato" proprio perché è uno standard ma mi sembra che sia una motivazione puerile...

una figura con 3 lati si chiama triangolo

Se SERVE, e abbiamo visto che SERVER anche a te poter far uscire da una VIEW record ordinati, ci sarà un motivo più SAGGIO che il semplice ERRORE che proponi tu.

Forse mi deve rispondere qualcuno di più preparato?

Io ignorante sono e ignorante rimango ma quando non capisco mi chiedo il perché delle cose non le prendo come oro colato.

vediamo di capirci una volta per tutte

hai 2 tabelle

clienti
fatture

con i seguenti campi (clienti.id, clienti.ragionesociale, clienti.via, clienti.localita, clienti.telefono, fatture.numero, fatture.data, fatture.importo e ovviamente fatture.idcliente)

creo una vista che prende tutti campi delle 2 tabelle e la chiamo vista1
create view vista1
as
select
clienti.id,
clienti.ragionesociale,
clienti.via,
clienti.localita,
clienti.telefono,
fatture.numero,
fatture.data,
fatture.importo
from clienti inner join fatture on clienti.id=fatture.idcliente go

ok adesso voglio il totale delle fatture per cliente e voglio i clienti in ordine crescente per ragionesociale
quindi creo una stored procedure che si appoggia alla vista vista1
create procedure totalefatturepercliente
as
select
ragionesociale,
sum(importo) as totale
from vista1
group by
ragionesociale
order by
ragionesociale

e adesso voglio la lista delle fatture ordinata per data e creo la stored procedure che si appoggia alla vista vista1

create procedure listafatture
as
select
numero,
data,
ragionesociale,
importo
from vista1
order by
data

ok ho finito se ho bisogno di altre liste creo le mie procedure che per comodità si appoggiano alla vista vista1 che mi evita di ripete i nomi dei campi, delle tabelle e i vari join.

Spero che adesso sia più chiaro, altrimenti ci troviamo al prossimo evento e ne discutiamo :-D

PS non è una minaccia ma una promessa

cyber_man ha scritto:

Per quanto riguarda il tuo esempio del quadrato, scusami, ma non sono d?accordo !

Un conto è un motivazione FISICA del tipo:
"SELECT sum(a), B, C FROM TAB1 GROUP BY C"

ed infatti la tua query è sintatticamente errata,
ovvero se selezioni i campi B e C devi includerli nel group by (leggi bene il mio esempio) e vedrai che ho coinvolto solo il campo ragionesociale

Questa select teoricamente è INAPPLICABILE ma non solo perché il "compilatore" dà errore ma perché "logicamente" non torna.
Che cosa me ne faccio del campo B, E' proprio SBAGLIATA! E' il quadrato con 3 lati !

ti ripeto leggi bene gli esempi che ti ho dato e la query corretta è

SELECT sum8a), B, C FROM TAB1 GROUP BY B,C

Differente è l'ORDER BY.
La mia obiezione sull'ORDER BY parte dal presupposto che non c'è una limitazione FISICA o un errore TEORICO ma, tu dici, solo un impedimento dato dal "compilatore" o ANSI o chi per lui.

allora non ci capiamo ansi non è un compilatore ma è lo standard che specifica SQL ovvero il linguaggio, lo standard dice testualmente che nelle viste non si usa order by

Senza stravolgere NIENTE delle filosofia SQL la select "SLECT A, B, B FROM TAB1 ORDER BY A" FUNZIONA !!!
Quindi LOGICAMENTE non è un quadrato con 3 lati ma è PERFETTA ! Non solo ma l'SQL la esegue perfettamente ! E' proprio corretta!
Ma in una vista non la posso mettere... Guarda un po? che scherzo mi fanno !!

per il semplice fatto che "SELECT A, B, B FROM TAB1 ORDER BY A" non è una vista ma una query

E' come dire: OK ti do un PC ma il mouse lo devi usare solo con la mano destra...
E se sono mancino ? Funziona tutto, lo sposti!
E tu mi rispondi NO è una regola che con la sinistra non lo puoi usare! E io ti chiedo: ma perché mi sembra impossibile!
E giùùùù... Discussioni che annoiano tutta la lista......

Bisticciamo, Bisticciamo e alla fine qualcuno ci spiega che il Mouse in questione è integrato nel lato destro della tastiera.
(che poi non sarebbe un motivo valido per non usarlo con la sinistra ma spero di essermi spiegato).

Ecco... Mi aspetto una risposta così ! E non una mera REGOLA!
Io sono un Ignorante (in senso culturale) e sono CERTO che dietro c'è una motivazione valida, ma quale ?

mi sorge spontanea la domanda ma hai letto e compreso quello che ho scritto e soprattutto hai capito cosa sono le viste??

Per quanto riguarda il tuo esempio con le tabelle invece, lo capisco ma io lo avrei risolto utilizzando, al posto delle tue SP, N VIEW ordinate con ORDER BY, perché devo scrivere del codice SQL quando lo posso disegnare graficamente?

ecco il problema, butta via il designer ed impara il codice, vedrai che ti sarà più chiaro.
Inoltre si disegna perfettamente anche una stored procedure.

Ciao.
Riccardo.

ciao

cyber_man ha scritto:

Se aveste fatto come me invece:
- Io chiamo il Query Designer e gli dico di campiare l'ordinamento della view.

Gli stai chiedendo l'impossibile visto che non si può definire l'ordinamento di una vista e che per tua ammissione non hai mai fatto uso del TOP 100 PERCENT.
Se gli chiedi una cosa del genere e lui non è sufficientemente "smart" la modifica la vedrai chissà quando... ;-)

Bye

Grazie per l'impegno, effettivamente con te siamo su un altro piano di discussione... Grazie del tempo che mi hai dedicato !

sql_server_e_mysql@forum.aspitalia.com
sql_server_e_mysql@forum.aspitalia.com] Per conto di l.bianchi wrote:

cyber_man ha scritto:


Stavo per scrivere "Mai usato TO 100 percent!" ma invece adesso mi accorgo che se in una view specifico un ordinamento allora TOP 100 PERCENT mi viene aggiunto automaticamente.
Non SOLO! Ma "SELECT * FROM (SELECT * FROM A ORDER BY a.a1)" da l'eerore di cui parlate!

Strano che non me ne sia mai accrto... Allora forse non sono tante le query dove uso ORDER BY!


Fammi capire un attimo... arriviamo al 20mo post di questo thread e solo ora emerge che hai capito che ci stiamo riferendo
all'ordinamento con il TOP 100 PERCENT... Sicuramente è lecito l'aver capito solo ora l'oggetto del contendere, ma un dubbio mi sta assalendo: a che cosa ti riferivi in precedenza visto che l'order by nelle viste NON è MAI stato consentito? In che modo cambi
l'ordinamento di un resultset se non fai uso del TOP 100 PERCENT e se l'order by senza il TOP 100 PERCENT non è MAI stato ammesso? E' lecito da parte mia supporre che parlavi erroneamente di viste quando di viste non si trattava?

Come dici successivamente in questa mail per me una VIEW teoricamente non è altro che una query salvata e riutilizzabile.
Io francamente non capisco il motivo TEORICO nell'inserimento della clausola TOP 100 PERCENT.
Se una VIEW non è altro che una query riusabile non vedo perchè la view debba sottostare a delle regole differenti dalle query.
"SELECT A, B FROM TAB1 ORDER BY A" funziona cosa ci incastra questo TOP 100 PERCENT ? Avranno bevuto ! :-))))
Già questo, per il mio piccolo cervello, è incomprensibile e chiaramente rende, ai miei occhi, le persone che hanno stilato lo standard un pò strane !
Ma giustamente tu obbietti: ma chi è questo cyber_man ? un bischero qualunque! e effettivamente non hai torno per niente !
Bischero ma curioso ! Perchè sicuramente, se l'hanno deciso, c'è un motivo!

Ma se non mi spieghi il motivo tecnico che spinge cotanti standard (ansi, mssql, oracle, db2, sybase, informix, ecc) a rendere "errato" come scrivi tu l'uso di ORDER BY io non lo capirò mai.

Tu dici che è "errato" proprio perché è uno standard ma mi sembra che sia una motivazione puerile...
Se SERVE, e abbiamo visto che SERVER anche a te poter far uscire da una VIEW record ordinati, ci sarà un motivo più SAGGIO che il semplice ERRORE che proponi tu.


Con la certezza di non riuscirci (ma che forse potrà essere utile ad altri che potranno leggere questo thread), una vista non è altro che una query memorizzata in tabelle di sistema. Tu potrai pure obiettare che in una query puoi specificare un ordinamento, ma chi vuole intendere capirà che una view serve UNICAMENTE a semplificare la scrittura di tale query. La definisco una volta, viene memorizzata in una tabella di sistema, e chiunque può riutilizzarla con una istruzione simile a

SELECT campi
FROM dbo.vw_MyView
WHERE condizione
ORDER BY criterio

semplificando di molto quello che potrebbe essere il codice di definizione della vista. Immagina la presenza di join tra una decina di tabelle, raggruppamenti, campi calcolati e tutto quello che vuoi (tranne che
ordinamenti) e che non viene compilata come invece accade per le stored procedure. Una vista quindi, nelle intenzioni di chi ha scritto gli standard ANSI, altro non è che una query il cui scopo, oltre a quello di semplificazione del codice, è all'insegna della riusabilità; tale riusabilità verrebbe meno con la presenza di un criterio di ordinamento (che puoi introdurre in maniera "artificiosa" con il workaround che ti ho
indicato) in quanto chi avrebbe bisogno di un criterio di ordinamento differente avrebbe 2 possibilità. La prima sarebbe quella di riscriversi una nuova vista (decisione più efficace ma che porta alla proliferazione del numero di oggetti); la seconda sarebbe quella di includere un diverso ordinamento nella query che richiama la vista (ricadendo nell'errore che evidenziavo nel mio post che costringe il sistema ad un doppio INUTILE ordinamento).

Scusa ma se tanto le VIEW, DI VIEW, DI VIEW vengono poi esplose in una sola "QUERONA", il motore SQL potrebbe usare l'ultimo ORDER BY quello cioè che poi deciderà l'ordine di invio dei dati al programma chiamante. In questo modo non ci sarebbero differenze TEORICHE tra query e view, io (l'unico s...zo sulla terra che lo usa) sarei contento e francamente tutto sarebbe più logico.

Altra cosa poi...
SE IO voglio decidere di far FARE 2 ordinamenti al motore del DB, sarò un demente, ma che gliene frega a motore del DB, li faccia e zitto, andrù più lento! Ma che li faccia !

No! Ci sono una manica di scenziati che me lo vietano SINTATTICAMENTE ! Ci deve essere di più!

In conclusione nessuno tra gli "autori" dei differenti standard che si sono succeduti nel tempo ha ritenuto utile apportare modifiche a tale "regola"
per consentire un ordinamento che, per la natura stessa come può essere utilizzata una vista nelle istruzioni DML, può essere ordinata a runtime.
Inoltre va anche detto che i produttori potrebbero aggiungere delle feature senza per questo andare contro lo standard ed anzi sono proprio le estensioni allo standard che oramai fanno la differenza tra i diversi prodotti. Forse se nessuno di loro ("autori dello standard ANSI-SQL" e produttori di dbms) ha sentito la mancanza dell'order by nelle viste forse forse tanto utile non deve essere... ;-)

Sei proprio un "signore", apprezzo lo sforzo ma ammetto di essere probabilmente l'unico bischero che una questa feature...
Ripeto però che non vedo il motivo TEORICO di compiere lo sofrzo di differenziare la sintassi SQL tra QUERY e VIEW...
Sempre SQL è, farlo interpretare ed eseguire in modo differente non mi risulta logicamente lineare... È strano...

E' come dire il linguaggio "Basic" ha una certa sintassi ma è vietato fare i cicli FOR all'interno di una istruzione IF THEN .... END IF. "E'.... No! In una "IF" il ciclo for non può essere usato...... "
Dimmi almeno se questo ragionamento ti torna ?

Se vuoi fatti promotore di una RFC e chissà che in uno dei prossimi standard ANSI SQL (dovremmo essere prossimi) non ci sia la
possibilità che venga introdotto...

Bye

Ciao.
Riccardo.