☺
Scritto da
The Lich
Übermensch
il 2008-06-28 10:59:00.0 alle 2008-06-28 10:59:00.0
Trollate totali: 21351
un esempio a caso: il bug della select che si sovrappone ai div in ie6.
Solo uno che si fuma roba pesante può aver lasciato passare un bug così schifoso e l' accrocchio che lo risolve (il trucchetto dell' iframe) sfrutta un altro bug.
Roba da barzelletta... due errori che finiscono per annullarsi a vicenda.
Naturalmente il bug è stato risolto in ie7. A proposito, se fate navigator.userAgent su ie7 viene fuori: Mozilla (compatible[etc etc etc]).
Implicita ammissione di inferiorità dei suoi prodotti cannati, ma non si vergogna neppure un po'?
The Lich
Solo uno che si fuma roba pesante può aver lasciato passare un bug così schifoso e l' accrocchio che lo risolve (il trucchetto dell' iframe) sfrutta un altro bug.
Roba da barzelletta... due errori che finiscono per annullarsi a vicenda.
Naturalmente il bug è stato risolto in ie7. A proposito, se fate navigator.userAgent su ie7 viene fuori: Mozilla (compatible[etc etc etc]).
Implicita ammissione di inferiorità dei suoi prodotti cannati, ma non si vergogna neppure un po'?
The Lich
☺
Scritto da
The Lich
Übermensch
il 2008-06-25 23:12:00.0 alle 2008-06-25 23:12:00.0
Trollate totali: 21351
- Scritto da:
> Dov'era la magistratura a Foggia?
>
> Già meglio cazzeggiare on il Berlusca o con
> Fabrizio Corona!
>
Foggia?
The Lich
☺
Scritto da
The Lich
Übermensch
il 2008-06-25 23:07:00.0 alle 2008-06-25 23:07:00.0
Trollate totali: 21351
- Scritto da:
>
> - Scritto da: The Lich
> > io mi sforzo di elevare questo forum di
> derelitti
> > proponendo un problema di natura teorica
> > (sottolineo teorica perchè dal punto di vista
> > pratico me ne sbatto del db e applico i vincoli
> > logici a livello di implementazione software)
> che
> > ha dato luogo anche a spunti di discussione
> > interessanti e alcuni link a testi meritevoli di
> > approfondimento e un celenterato sassofonista
> > qualunque deve uscirsene con battute squallide
> > tipo:
> >
> > Comunque alla fine per la collezione di sassi
> > del licchione non vale la pena. Farebbe meglio a
> > fare tanti file di
> > testo:
> >
> > "Questo sasso fatto cosi` l'ho raccolto mentre
> > passeggiavo sul viottolo che va al lago e
> pensavo
> > a quanto e` figo essere un
> > lich"
> >
> > e passarli sotto un indicizzatore. Troll occhi
> di
> > fuori
> > Free-text search rulez! ?
> >
> > Questo è un vero scandalo, una vergogna.
> >
> > Btw il vecchio caprone in canotta ha detto nulla
> > della confesercenti che per poco non si mangiava
> > vivo il nanetto da giardino?
> >
> > Tutti comunisti quelli della confesercenti?
> >
>
>
> C'è stato un tizio che mi ha colpito, ti ha
> scritto qualcosa sul genere "ora capirai il
> valore delle relazioni umane".
il tizio non ha capito un cazzo
> Io che non sono
> hikikomori come il sassofono (che ha provato ad
> aiutarti per non so quale ragione),
il bello è che non ho bisogno di nessun aiuto, dal punto di vista pratico so benissimo come implementare il db in access, php + mysql e quando avrò finito di studiare c++, lo riscriverò in c++ + mysql
> te lo ripeto:
sentiamo la ripetizione delle boiate
> perché mai bisognerebbe sentirsi in dovere
nessun dovere, ho sollevato una questione teorica che pensavo potesse essere di un qualche interesse in un forum di nerd informatici
> di aiutare una "persona" che rifiuta ogni
> contatto umano, che aborre l'amicizia, che
> aspira ad un cuore di freddo metallo?
perchè la mia domanda non ha assolutamente nulla a che fare con i contatti umani e l' amicizia,
se proprio vogliamo vederla su questo piano, lo scambio di informazioni fra macchine è la grande conquista delle reti di calcolatori da arpanet in avanti
> Sarebbe come se provassi a dialogare con la
> macchinetta del caffé, onestamente.
potresti provarci, ma dubito che avrebbe qualcosa di interessante da darti, qualcosa che possa arrichire il tuo bagaglio di informazioni
> Tu non sei interessante dal pdv umano, quindi se
> vuoi essere una macchina comportati come una
> macchina,
mi comporto come tale, ma non come il tostapane con cui ti identifichi tu
ovvero, non proiettare
> se funzioni bene, se non funzioni o ti
> fai funzionare da solo (aka comprati un libro,
> usa la testa, creati da zero un linguaggio di
> programmazione a basso livello e relativi
> compilatori, usa più Blender, che ne so...) o ti
> si porta in discarica assieme alle lavatrici
> rotte.
tu hai un' idea del funzionamento delle macchine che esiste solo nella tua mente
> E' quello che vuoi, essere un freddo robot, e io
> non lo contesto. Mi piace solo che le persone
> siano coerenti con le loro scelte.
>
tu invece sei coerente: scrivi boiate senza neppure rendertene conto
The Lich
>
> - Scritto da: The Lich
> > io mi sforzo di elevare questo forum di
> derelitti
> > proponendo un problema di natura teorica
> > (sottolineo teorica perchè dal punto di vista
> > pratico me ne sbatto del db e applico i vincoli
> > logici a livello di implementazione software)
> che
> > ha dato luogo anche a spunti di discussione
> > interessanti e alcuni link a testi meritevoli di
> > approfondimento e un celenterato sassofonista
> > qualunque deve uscirsene con battute squallide
> > tipo:
> >
> > Comunque alla fine per la collezione di sassi
> > del licchione non vale la pena. Farebbe meglio a
> > fare tanti file di
> > testo:
> >
> > "Questo sasso fatto cosi` l'ho raccolto mentre
> > passeggiavo sul viottolo che va al lago e
> pensavo
> > a quanto e` figo essere un
> > lich"
> >
> > e passarli sotto un indicizzatore. Troll occhi
> di
> > fuori
> > Free-text search rulez! ?
> >
> > Questo è un vero scandalo, una vergogna.
> >
> > Btw il vecchio caprone in canotta ha detto nulla
> > della confesercenti che per poco non si mangiava
> > vivo il nanetto da giardino?
> >
> > Tutti comunisti quelli della confesercenti?
> >
>
>
> C'è stato un tizio che mi ha colpito, ti ha
> scritto qualcosa sul genere "ora capirai il
> valore delle relazioni umane".
il tizio non ha capito un cazzo
> Io che non sono
> hikikomori come il sassofono (che ha provato ad
> aiutarti per non so quale ragione),
il bello è che non ho bisogno di nessun aiuto, dal punto di vista pratico so benissimo come implementare il db in access, php + mysql e quando avrò finito di studiare c++, lo riscriverò in c++ + mysql
> te lo ripeto:
sentiamo la ripetizione delle boiate
> perché mai bisognerebbe sentirsi in dovere
nessun dovere, ho sollevato una questione teorica che pensavo potesse essere di un qualche interesse in un forum di nerd informatici
> di aiutare una "persona" che rifiuta ogni
> contatto umano, che aborre l'amicizia, che
> aspira ad un cuore di freddo metallo?
perchè la mia domanda non ha assolutamente nulla a che fare con i contatti umani e l' amicizia,
se proprio vogliamo vederla su questo piano, lo scambio di informazioni fra macchine è la grande conquista delle reti di calcolatori da arpanet in avanti
> Sarebbe come se provassi a dialogare con la
> macchinetta del caffé, onestamente.
potresti provarci, ma dubito che avrebbe qualcosa di interessante da darti, qualcosa che possa arrichire il tuo bagaglio di informazioni
> Tu non sei interessante dal pdv umano, quindi se
> vuoi essere una macchina comportati come una
> macchina,
mi comporto come tale, ma non come il tostapane con cui ti identifichi tu
ovvero, non proiettare
> se funzioni bene, se non funzioni o ti
> fai funzionare da solo (aka comprati un libro,
> usa la testa, creati da zero un linguaggio di
> programmazione a basso livello e relativi
> compilatori, usa più Blender, che ne so...) o ti
> si porta in discarica assieme alle lavatrici
> rotte.
tu hai un' idea del funzionamento delle macchine che esiste solo nella tua mente
> E' quello che vuoi, essere un freddo robot, e io
> non lo contesto. Mi piace solo che le persone
> siano coerenti con le loro scelte.
>
tu invece sei coerente: scrivi boiate senza neppure rendertene conto
The Lich
☺
Scritto da
The Lich
Übermensch
il 2008-06-25 22:59:00.0 alle 2008-06-25 22:59:00.0
Trollate totali: 21351
- Scritto da:
> non hai risposto a questa domanda...:
>
> non hai risposto a questa domanda...:
>
☺
Scritto da
The Lich
Übermensch
il 2008-06-25 22:51:00.0 alle 2008-06-25 22:51:00.0
Trollate totali: 21351
- Scritto da: avvelentani
>
> - Scritto da:
> >
> > > O fai come ti ho detto sotto o fai una tabella
> > > luogo: provincia, regione e localita hanno un
> > > luogo come chiave esterna e anche
> > > datopocodefinito ce l'ha, che pero` e` opaco e
> > > error-prone.
> >
> > postgresql ha questa bella cosa fuori standard
>
> >
> >
>
MA checcazzo ne so
Ad
http://sallo.it
LO SAI? Allora NON fa per te. NON LO SAI? Allora non ti serve.
☺
Scritto da
The Lich
Übermensch
il 2008-06-25 22:47:00.0 alle 2008-06-25 22:47:00.0
Trollate totali: 21351
- Scritto da: Guido Angeli
>
> Poi hai manie di persecuzione, ogniqualvolta uno
> ti sfotte pensi che sia io, e rilanci con insulti
> davvero spropositati, occhi bovini, orecchie
> asinine, faccia rotonda, capelli dell'altra
> (parli della mia foto con l'eleonora, quella
> davk?).....mah, i casi sono due, o pensi davvero
> che sia io il cattivone che ti tira i nomi dietro
> sfottendoti per l'aspetto, e allora mi stai
> offendendo, pensavo di averti fatto capire che se
> c'ho da dire cose le dico faccia a faccia, senza
> giri di parole, ma mi credi così codardo?
>
>
> oppure in realtà ti rode di qualcosa e ne
> approfitti delle frecciate degli anonimi per
> shit-testarmi, ma sò cazzi tua mò, io te l'avevo
> detto che volevo andare a prendere il gelato da
> Gaggio (questo all'epoca in cui facevo
> Clistereblu) e vedere Staglieno! Mò ti attacchi,
> e io mi faccio (altre foto tra i capelli di)
> altre tipe, tié! E tu morirai nubile aka
> zitellona sognando immaginifici brillocchi, tié!
>
>
> ps: oggi sono andato dal parrucchiere e gli ho
> detto che sono stufo di sembrare un bravo
> ragazzo, e dopo il trattamento ora mi sento
> davvero gnocco! mi mancano solo un paio di
> genovesi di due taglie più grandi indossati a
> metà culo e la maglietta di Casto Immanuel
> (proprio quella 50 bocca 100 ammore) e sarò, come
> Figaro un giovane che veste giovane! Alla
> facciazza tua e dei tuoi 40 anni!
>
>
> avvelenato in piena crisi di mezz'età
>
> ps: mi loggo per quanto possa servire il log con
> un nick la cui password è come la bagianna di
> Sgualvagina
>
invalnàto, ancora non sei riuscito a ripescare la password del nickname invalnatèsco?
The Lich
☺
Scritto da
The Lich
Übermensch
il 2008-06-25 22:41:00.0 alle 2008-06-25 22:41:00.0
Trollate totali: 21351
- Scritto da:
> In ogni tabella (località, provincia, regione,
> paese, pianeta...) aggiungi ai record esistenti
> un record
> indefinito.
>
> Immagino un'interfaccia dove assegni al record di
> un minerale i valori dei vari campi da caselle a
> discesa, partendo dalle proprietà gerarchicamente
> superiori - per un minerale di cui sai tutto
> sceglieresti:
>
> Stato: Italia
>
> (la casella delle regioni si popola con le
> regioni
> d'Italia)
>
> Regione: Piemonte
>
> (la casella delle province si popola con le
> province
> piemontesi)
>
> Provincia: Torino
>
> (la casella dei comuni si popola con i comuni
> della provincia di
> Torino)
>
> Supponi ora di introdurre i campi indefiniti
> negli elenchi, e di classificare un minerale di
> cui sai solo che proviene dal
> Piemonte.
>
> Stato: Italia
>
> (la casella delle regioni si popola con le
> regioni d'Italia, più "regione
> indefinita")
>
> Regione: Piemonte
>
> (la casella delle province si popola con le
> province piemontesi, più "provincia
> indefinita")
>
> Provincia: Indefinita
>
> (la casella dei comuni si popola con la sola voce
> "indefinito")
>
> Mi resta qualche dubbio sull'appartenenza degli
> indefiniti o meno ai record gerarchicamente
> superiori: se ad esempio la provincia
> "indefinita" che scegli dall'elenco delle
> province del Piemonte sia, a livello teorico, una
> "provincia indefinita della regione Piemonte"
> distinta dalla "provincia indefinita della
> regione Liguria" ma non so se questo dubbio abbia
> qualche effetto
> pratico.
un altro che mi dice tutto quello che so già
porca zozza a livello pratico so benissimo come implementare sto cazzo di database, la mia domanda era sul piano teorico, non pratico-implementativo, quello so benissimo applicarlo da solo
inutile dirle, finora le unoche risposte sensate sono del sassofono e dell' anonimo, penso alex.tg o chi per lui
The Lich
☺
Scritto da
The Lich
Übermensch
il 2008-06-25 22:39:00.0 alle 2008-06-25 22:39:00.0
Trollate totali: 21351
- Scritto da:
> - Scritto da:
> > Guarda domani ti spiego come fare.
> > Se spiegavi subito a cosa ti serviva non mi
> > sorbivo 89 post di cazzate e te lo spiegavo
> > stasera.
> >
> > Ciao
>
> Allora, vado a memoria che non ho tempo (e
> voglia) di rileggermi
> tutto.
>
> Ti servono 4 tabelle.
>
> Una con id_nazione e descrizione
> Una con id_regione id_nazione e descrizione della
> regione
> Una con id_provincia id_regione e descrizione
> della
> provincia
>
> In queste tabelle il primo ID è chiave primaria
>
> Infine una quarta tabella con tutti i campi che
> ti servono più 3 colonne: id_nazione, id_regione,
> id_provincia che possono anche essere NULL (e il
> valore di default sarà
> NULL).
>
> Facendo così, con le join opportune puoi tirare
> fuori tutti i dati che ti servono anche se hai
> solo uno dei tre ID (anzi avrai sempre uno solo
> dei 3
> ID).
>
> Fine.
se dovevo leggere questo consiglio potevo anche rileggermi quello che ho scritto io, grazie comunque
The Lich
☺
Scritto da
The Lich
Übermensch
il 2008-06-25 22:37:00.0 alle 2008-06-25 22:37:00.0
Trollate totali: 21351
io mi sforzo di elevare questo forum di derelitti proponendo un problema di natura teorica (sottolineo teorica perchè dal punto di vista pratico me ne sbatto del db e applico i vincoli logici a livello di implementazione software) che ha dato luogo anche a spunti di discussione interessanti e alcuni link a testi meritevoli di approfondimento e un celenterato sassofonista qualunque deve uscirsene con battute squallide tipo:
Comunque alla fine per la collezione di sassi del licchione non vale la pena. Farebbe meglio a fare tanti file di testo:
"Questo sasso fatto cosi` l'ho raccolto mentre passeggiavo sul viottolo che va al lago e pensavo a quanto e` figo essere un lich"
e passarli sotto un indicizzatore. Troll occhi di fuori
Free-text search rulez! ?
Questo è un vero scandalo, una vergogna.
Btw il vecchio caprone in canotta ha detto nulla della confesercenti che per poco non si mangiava vivo il nanetto da giardino?
Tutti comunisti quelli della confesercenti?
The Lich
Comunque alla fine per la collezione di sassi del licchione non vale la pena. Farebbe meglio a fare tanti file di testo:
"Questo sasso fatto cosi` l'ho raccolto mentre passeggiavo sul viottolo che va al lago e pensavo a quanto e` figo essere un lich"
e passarli sotto un indicizzatore. Troll occhi di fuori
Free-text search rulez! ?
Questo è un vero scandalo, una vergogna.
Btw il vecchio caprone in canotta ha detto nulla della confesercenti che per poco non si mangiava vivo il nanetto da giardino?
Tutti comunisti quelli della confesercenti?
The Lich
E TU Lo Sai o no?
Ad
http://sallo.it
LO SAI? Allora NON fa per te. NON LO SAI? Allora non ti serve.
☺
Scritto da
The Lich
Übermensch
il 2008-06-24 22:52:00.0 alle 2008-06-24 22:52:00.0
Trollate totali: 21351
- Scritto da:
>
> - Scritto da: The Lich
> > - Scritto da:
> > > - Scritto da: The Lich
> > > > - Scritto da:
> > > > >
> > > > > - Scritto da: The Lich
> > > > > > (+ teorica che pratica)
> > > > > > in pratica è facile da risolvere, il mio
> > > > dubbio
> > > > > è
> > > > > > piuttosto di natura
> > > > > > teorica.
> > > > > >
> > > > > > Comunque, supponiamo di avere un insieme
> > di
> > > > dati
> > > > > > ordinati
> > > > > > gerarchicamente:
> > > > > >
> > > > > > Stato
> > > > > > Regione
> > > > > > Provincia
> > > > > > Località
> > > > > >
> > > > > > si crea un insieme di tabelle in cui la
> > > > > relazione
> > > > > > gerarchica o di ereditarietà viene
> > espressa
> > > > > > esportando nella tabella inferiore l' id
> > del
> > > > > > campo superiore, ad
> > > > > > esempio:
> > > > > >
> > > > > > tabella provincia:
> > > > > > id_provincia
> > > > > > id_regione
> > > > > > nome_provincia
> > > > > >
> > > > > > supponiamo poi di avere un dato definito
> > in
> > > > > > maniera tale che un suo campo è la
> > località.
> > > > Fin
> > > > > > qui nulla di strano, la tabella del dato
> > > avrà
> > > > un
> > > > > > id_localita e con una serie di join sarà
> > > > > > possibile ricostruire tutte le relazioni
> > > dalla
> > > > > > località allo
> > > > > > stato.
> > > > > >
> > > > > > Supponiamo ora di avere invece un dato
> > poco
> > > > > > definito, nel senso che non è in
> relazione
> > > con
> > > > > > una località ma con una provincia o
> > > > addirittura
> > > > > > uno
> > > > > > stato.
> > > > > > In pratica si potrebbero importare nella
> > > > tabella
> > > > > > di questo dato tutti gli id: id_stato,
> > > > > > id_regione, id_provincia etc come campi
> > non
> > > > > > obbligatori e pertanto lasciare vuoti
> > quelli
> > > > non
> > > > > > definiti.
> > > > > >
> > > > > > Il mio dubbio è il seguente: questo modo
> > di
> > > > > > procedere in un databse relazionale come
> > > mYSQL
> > > > > > non viola le regole per la riduzione
> alla
> > > > terza
> > > > > > forma normale?
> > > > > >
> > > > > > E' un approccio teoricamente legittimo
> o
> è
> > > > > > applicabile solo nella pratica
> > > > > > comune?
> > > > > >
> > > > >
> > > > > se pensiamo a stato provincia località
> come
> > > alle
> > > > > specializzazioni di uno stesso concetto,
> > > > chiamato
> > > > > ad esempio zona, potresti produrre una
> > > relazione
> > > > > tra zona e dato
> > > > > poco_definito
> > > > >
> > > > > tradotto poi dallo schema concettuale allo
> > > > schema
> > > > > logico diverrebbero comunque tre tabelle e
> > se
> > > la
> > > > > relazione è 1-n tre campi nella tabella
> che
> > > > > rappresenta il dato
> > > > > poco_definito
> > > >
> > > > gira e rigira esattamente come ho fatto:
> > invece
> > > > di zona località e gli id nella tabella del
> > dato
> > > > poco
> > > > definito
> > > >
> > > > quello che volevo sapere non era l'
> > > > implementazione pratica ma la correttezza
> > > > teorica
> > > >
> > > >
> > >
> >
> --------------------------------------------------
> > > > Modificato dall' autore il 24 giugno 2008
> > 22.01
> > > >
> > >
> >
> --------------------------------------------------
> > >
> > > per questo ho parlato del modello concettuale:
> > > hai tre entità derivate da un'unica entità
> padre
> >
> > in realtà sono in relazione di ereditarietà
> l'una
> > rispetto all'
> > altra
>
> se intendi la relazione gerarchica
> stato->regione->provincia->sticazzi quella è
> un'altra relazione diversa dell'entità padre su
> sé stessa, ma non è di quella che sto
> parlando.
>
> Se invece intendi ereditarietà Stato(Zona)
> Regione(Zona) Provincia(Zona) Sticazzi(Zona)
> allora hai capito bene.
> *
>
> Per spiegarmi meglio dovrei disegnartelo e temo
> che non lo
> farò
>
> >
> > > e la relazione del dato poco definito è con
> > > l'entità
> > > padre
> >
> > può esserlo con tutte e tre questo è il
> problema,
>
> * No, hai capito male
>
> > potrò sbagliarmi ma la teoria relazionale non
> > risolve bene questo problema, a naso direi che
> > viene modellato meglio da un database ad oggetti
> > che ammette
> > ereditarietà
> >
> > > Il problema ti si presenta dopo, quando vai a
> > > rappresentare questo modello con delle tabelle
> > > perché non puoi rappresentare in modo
> > > soddisfacente il legame tra l'entità base e
> > > quelle
> > > derivate...
> >
> > per me è un modo di complicare le cose...
>
> ma spiega a livello teorico quello che hai fatto
> a
> naso
>
> >
> > tutte le entità derivano da stato e sono in
> > relazione gerarchica, su questo non si
> > discute
> >
no no adesso ho capito cosa intendi
il fatto è che logicamente sono anche in relazione gerarchica fra loro, non solo con zona
ie tu introduci nel discorso un "terzo incomodo": potrei benissimo cancellare la tabella zona e mettere direttamente nella tabella del dato:
id_stato
id_regione
id_provincia
id_localita
tutti campi facoltativi
però così perderei la relazione esistente fra stato regione provincia e località e dovrei reintrodurla a livello di amministrazione del database (inserimento/modifica)
The Lich
☺
Scritto da
The Lich
Übermensch
il 2008-06-24 22:47:00.0 alle 2008-06-24 22:47:00.0
Trollate totali: 21351
- Scritto da:
>
> > O fai come ti ho detto sotto o fai una tabella
> > luogo: provincia, regione e localita hanno un
> > luogo come chiave esterna e anche
> > datopocodefinito ce l'ha, che pero` e` opaco e
> > error-prone.
>
> postgresql ha questa bella cosa fuori standard
>
>
☺
Scritto da
The Lich
Übermensch
il 2008-06-24 22:42:00.0 alle 2008-06-24 22:42:00.0
Trollate totali: 21351
- Scritto da: nathan71
>
> - Scritto da: The Lich
> > è tutta una cagata burocratica, probabilmente l'
> > azienda lo doveva sospendere e basta fino alla
> > fine del processo e poi cacciarlo a pedate con
> > ogni ragione del
> > caso
>
> ogni datore di lavoro dovrebbere essere libero di
> licenziare chi gli pare quando gli pare.
>
ogni motociclista dovrebbe essere obbligato ad un frontale contro un tir
The Lich
☺
Scritto da
The Lich
Übermensch
il 2008-06-24 22:41:00.0 alle 2008-06-24 22:41:00.0
Trollate totali: 21351
- Scritto da:
>
> - Scritto da: The Lich
>
> >
> > Supponiamo ora di avere invece un dato poco
> > definito, nel senso che non è in relazione con
> > una località ma con una provincia o addirittura
> > uno
> > stato.
>
> c'è qualcosa che non funge nell'analisi dei
> requisiti
>
funge benissimo idiota e ti spiego anche il perchè, per mia degnazione.
Voglio fare il database della mia collezione di minerali e non conosco sempre la provenienza precisa.
Di quelli che ho raccolto io ti so dire le coordinate UTM ad 8 cifre, di minerali acquistati tempo fa magari da mio babbo, è già tanto se so che vengono dal Brasile.
Bamba!
The Lich
☺
Scritto da
The Lich
Übermensch
il 2008-06-24 22:20:00.0 alle 2008-06-24 22:20:00.0
Trollate totali: 21351
- Scritto da: exsinistro
> In realta è la magistratura rossa intera che si è
> imbastardita.
>
>
☺
Scritto da
The Lich
Übermensch
il 2008-06-24 22:15:00.0 alle 2008-06-24 22:15:00.0
Trollate totali: 21351
- Scritto da: Fatalmente2
> Sulle fobie è 'Qualcosa è cambiato' e non
> solo...tratta anche il tema della misoginia in
> modo
> eccellente.
>
>
> Ne consiglio la visione a Lich e a qualcun
> altro. Io mi lavavo spesso le mani, ho smesso!
>
>
>
>
> Sulle fobie è 'Qualcosa è cambiato' e non
> solo...tratta anche il tema della misoginia in
> modo
> eccellente.
>
>
> Ne consiglio la visione a Lich e a qualcun
> altro. Io mi lavavo spesso le mani, ho smesso!
>
>
>
>
☺
Scritto da
The Lich
Übermensch
il 2008-06-24 22:14:00.0 alle 2008-06-24 22:14:00.0
Trollate totali: 21351
- Scritto da: shevathas
>
> - Scritto da: The Lich
> >
> > - Scritto da:
> > >
> > > - Scritto da: The Lich
> > > > (+ teorica che pratica)
> > > > in pratica è facile da risolvere, il mio
> > dubbio
> > > è
> > > > piuttosto di natura
> > > > teorica.
> > > >
> > > > Comunque, supponiamo di avere un insieme di
> > dati
> > > > ordinati
> > > > gerarchicamente:
> > > >
> > > > Stato
> > > > Regione
> > > > Provincia
> > > > Località
> > > >
> > > > si crea un insieme di tabelle in cui la
> > > relazione
> > > > gerarchica o di ereditarietà viene espressa
> > > > esportando nella tabella inferiore l' id del
> > > > campo superiore, ad
> > > > esempio:
> > > >
> > > > tabella provincia:
> > > > id_provincia
> > > > id_regione
> > > > nome_provincia
> > > >
> > > > supponiamo poi di avere un dato definito in
> > > > maniera tale che un suo campo è la località.
> > Fin
> > > > qui nulla di strano, la tabella del dato
> avrà
> > un
> > > > id_localita e con una serie di join sarà
> > > > possibile ricostruire tutte le relazioni
> dalla
> > > > località allo
> > > > stato.
> > > >
> > > > Supponiamo ora di avere invece un dato poco
> > > > definito, nel senso che non è in relazione
> con
> > > > una località ma con una provincia o
> > addirittura
> > > > uno
> > > > stato.
> > > > In pratica si potrebbero importare nella
> > tabella
> > > > di questo dato tutti gli id: id_stato,
> > > > id_regione, id_provincia etc come campi non
> > > > obbligatori e pertanto lasciare vuoti quelli
> > non
> > > > definiti.
> > > >
> > > > Il mio dubbio è il seguente: questo modo di
> > > > procedere in un databse relazionale come
> mYSQL
> > > > non viola le regole per la riduzione alla
> > terza
> > > > forma normale?
> > > >
> > > > E' un approccio teoricamente legittimo o è
> > > > applicabile solo nella pratica
> > > > comune?
> > > >
> > > la seconda che hai detto
> >
> > mi piacerebbe che tu espandessi il concetto
> >
> >
> come mai vieni a chiedere queste cose al forum ?
> aristotele non ne aveva parlato ?
se non lo sapete voi cattolici che credete ancora che il sole giri intorno alla terra e che le donne non partecipino attivamente al processo riproduttivo...
The Lich
>
> - Scritto da: The Lich
> >
> > - Scritto da:
> > >
> > > - Scritto da: The Lich
> > > > (+ teorica che pratica)
> > > > in pratica è facile da risolvere, il mio
> > dubbio
> > > è
> > > > piuttosto di natura
> > > > teorica.
> > > >
> > > > Comunque, supponiamo di avere un insieme di
> > dati
> > > > ordinati
> > > > gerarchicamente:
> > > >
> > > > Stato
> > > > Regione
> > > > Provincia
> > > > Località
> > > >
> > > > si crea un insieme di tabelle in cui la
> > > relazione
> > > > gerarchica o di ereditarietà viene espressa
> > > > esportando nella tabella inferiore l' id del
> > > > campo superiore, ad
> > > > esempio:
> > > >
> > > > tabella provincia:
> > > > id_provincia
> > > > id_regione
> > > > nome_provincia
> > > >
> > > > supponiamo poi di avere un dato definito in
> > > > maniera tale che un suo campo è la località.
> > Fin
> > > > qui nulla di strano, la tabella del dato
> avrà
> > un
> > > > id_localita e con una serie di join sarà
> > > > possibile ricostruire tutte le relazioni
> dalla
> > > > località allo
> > > > stato.
> > > >
> > > > Supponiamo ora di avere invece un dato poco
> > > > definito, nel senso che non è in relazione
> con
> > > > una località ma con una provincia o
> > addirittura
> > > > uno
> > > > stato.
> > > > In pratica si potrebbero importare nella
> > tabella
> > > > di questo dato tutti gli id: id_stato,
> > > > id_regione, id_provincia etc come campi non
> > > > obbligatori e pertanto lasciare vuoti quelli
> > non
> > > > definiti.
> > > >
> > > > Il mio dubbio è il seguente: questo modo di
> > > > procedere in un databse relazionale come
> mYSQL
> > > > non viola le regole per la riduzione alla
> > terza
> > > > forma normale?
> > > >
> > > > E' un approccio teoricamente legittimo o è
> > > > applicabile solo nella pratica
> > > > comune?
> > > >
> > > la seconda che hai detto
> >
> > mi piacerebbe che tu espandessi il concetto
> >
> >
> come mai vieni a chiedere queste cose al forum ?
> aristotele non ne aveva parlato ?
se non lo sapete voi cattolici che credete ancora che il sole giri intorno alla terra e che le donne non partecipino attivamente al processo riproduttivo...
The Lich
☺
Scritto da
The Lich
Übermensch
il 2008-06-24 22:11:00.0 alle 2008-06-24 22:11:00.0
Trollate totali: 21351
- Scritto da:
> - Scritto da: The Lich
> > - Scritto da:
> > >
> > > - Scritto da: The Lich
> > > > (+ teorica che pratica)
> > > > in pratica è facile da risolvere, il mio
> > dubbio
> > > è
> > > > piuttosto di natura
> > > > teorica.
> > > >
> > > > Comunque, supponiamo di avere un insieme di
> > dati
> > > > ordinati
> > > > gerarchicamente:
> > > >
> > > > Stato
> > > > Regione
> > > > Provincia
> > > > Località
> > > >
> > > > si crea un insieme di tabelle in cui la
> > > relazione
> > > > gerarchica o di ereditarietà viene espressa
> > > > esportando nella tabella inferiore l' id del
> > > > campo superiore, ad
> > > > esempio:
> > > >
> > > > tabella provincia:
> > > > id_provincia
> > > > id_regione
> > > > nome_provincia
> > > >
> > > > supponiamo poi di avere un dato definito in
> > > > maniera tale che un suo campo è la località.
> > Fin
> > > > qui nulla di strano, la tabella del dato
> avrà
> > un
> > > > id_localita e con una serie di join sarà
> > > > possibile ricostruire tutte le relazioni
> dalla
> > > > località allo
> > > > stato.
> > > >
> > > > Supponiamo ora di avere invece un dato poco
> > > > definito, nel senso che non è in relazione
> con
> > > > una località ma con una provincia o
> > addirittura
> > > > uno
> > > > stato.
> > > > In pratica si potrebbero importare nella
> > tabella
> > > > di questo dato tutti gli id: id_stato,
> > > > id_regione, id_provincia etc come campi non
> > > > obbligatori e pertanto lasciare vuoti quelli
> > non
> > > > definiti.
> > > >
> > > > Il mio dubbio è il seguente: questo modo di
> > > > procedere in un databse relazionale come
> mYSQL
> > > > non viola le regole per la riduzione alla
> > terza
> > > > forma normale?
> > > >
> > > > E' un approccio teoricamente legittimo o è
> > > > applicabile solo nella pratica
> > > > comune?
> > > >
> > >
> > > se pensiamo a stato provincia località come
> alle
> > > specializzazioni di uno stesso concetto,
> > chiamato
> > > ad esempio zona, potresti produrre una
> relazione
> > > tra zona e dato
> > > poco_definito
> > >
> > > tradotto poi dallo schema concettuale allo
> > schema
> > > logico diverrebbero comunque tre tabelle e se
> la
> > > relazione è 1-n tre campi nella tabella che
> > > rappresenta il dato
> > > poco_definito
> >
> > gira e rigira esattamente come ho fatto: invece
> > di zona località e gli id nella tabella del dato
> > poco
> > definito
> >
> > quello che volevo sapere non era l'
> > implementazione pratica ma la correttezza
> > teorica
> >
> >
> --------------------------------------------------
> > Modificato dall' autore il 24 giugno 2008 22.01
> >
> --------------------------------------------------
>
> per questo ho parlato del modello concettuale:
> hai tre entità derivate da un'unica entità padre
in realtà sono in relazione di ereditarietà l'una rispetto all' altra
> e la relazione del dato poco definito è con
> l'entità
> padre
può esserlo con tutte e tre questo è il problema, potrò sbagliarmi ma la teoria relazionale non risolve bene questo problema, a naso direi che viene modellato meglio da un database ad oggetti che ammette ereditarietà
> Il problema ti si presenta dopo, quando vai a
> rappresentare questo modello con delle tabelle
> perché non puoi rappresentare in modo
> soddisfacente il legame tra l'entità base e
> quelle
> derivate...
per me è un modo di complicare le cose...
tutte le entità derivano da stato e sono in relazione gerarchica, su questo non si discute
The Lich
-----------------------------------------------------------
Modificato dall' autore il 24 giugno 2008 22.12
-----------------------------------------------------------
> - Scritto da: The Lich
> > - Scritto da:
> > >
> > > - Scritto da: The Lich
> > > > (+ teorica che pratica)
> > > > in pratica è facile da risolvere, il mio
> > dubbio
> > > è
> > > > piuttosto di natura
> > > > teorica.
> > > >
> > > > Comunque, supponiamo di avere un insieme di
> > dati
> > > > ordinati
> > > > gerarchicamente:
> > > >
> > > > Stato
> > > > Regione
> > > > Provincia
> > > > Località
> > > >
> > > > si crea un insieme di tabelle in cui la
> > > relazione
> > > > gerarchica o di ereditarietà viene espressa
> > > > esportando nella tabella inferiore l' id del
> > > > campo superiore, ad
> > > > esempio:
> > > >
> > > > tabella provincia:
> > > > id_provincia
> > > > id_regione
> > > > nome_provincia
> > > >
> > > > supponiamo poi di avere un dato definito in
> > > > maniera tale che un suo campo è la località.
> > Fin
> > > > qui nulla di strano, la tabella del dato
> avrà
> > un
> > > > id_localita e con una serie di join sarà
> > > > possibile ricostruire tutte le relazioni
> dalla
> > > > località allo
> > > > stato.
> > > >
> > > > Supponiamo ora di avere invece un dato poco
> > > > definito, nel senso che non è in relazione
> con
> > > > una località ma con una provincia o
> > addirittura
> > > > uno
> > > > stato.
> > > > In pratica si potrebbero importare nella
> > tabella
> > > > di questo dato tutti gli id: id_stato,
> > > > id_regione, id_provincia etc come campi non
> > > > obbligatori e pertanto lasciare vuoti quelli
> > non
> > > > definiti.
> > > >
> > > > Il mio dubbio è il seguente: questo modo di
> > > > procedere in un databse relazionale come
> mYSQL
> > > > non viola le regole per la riduzione alla
> > terza
> > > > forma normale?
> > > >
> > > > E' un approccio teoricamente legittimo o è
> > > > applicabile solo nella pratica
> > > > comune?
> > > >
> > >
> > > se pensiamo a stato provincia località come
> alle
> > > specializzazioni di uno stesso concetto,
> > chiamato
> > > ad esempio zona, potresti produrre una
> relazione
> > > tra zona e dato
> > > poco_definito
> > >
> > > tradotto poi dallo schema concettuale allo
> > schema
> > > logico diverrebbero comunque tre tabelle e se
> la
> > > relazione è 1-n tre campi nella tabella che
> > > rappresenta il dato
> > > poco_definito
> >
> > gira e rigira esattamente come ho fatto: invece
> > di zona località e gli id nella tabella del dato
> > poco
> > definito
> >
> > quello che volevo sapere non era l'
> > implementazione pratica ma la correttezza
> > teorica
> >
> >
> --------------------------------------------------
> > Modificato dall' autore il 24 giugno 2008 22.01
> >
> --------------------------------------------------
>
> per questo ho parlato del modello concettuale:
> hai tre entità derivate da un'unica entità padre
in realtà sono in relazione di ereditarietà l'una rispetto all' altra
> e la relazione del dato poco definito è con
> l'entità
> padre
può esserlo con tutte e tre questo è il problema, potrò sbagliarmi ma la teoria relazionale non risolve bene questo problema, a naso direi che viene modellato meglio da un database ad oggetti che ammette ereditarietà
> Il problema ti si presenta dopo, quando vai a
> rappresentare questo modello con delle tabelle
> perché non puoi rappresentare in modo
> soddisfacente il legame tra l'entità base e
> quelle
> derivate...
per me è un modo di complicare le cose...
tutte le entità derivano da stato e sono in relazione gerarchica, su questo non si discute
The Lich
-----------------------------------------------------------
Modificato dall' autore il 24 giugno 2008 22.12
-----------------------------------------------------------
☺
Scritto da
The Lich
Übermensch
il 2008-06-24 22:08:00.0 alle 2008-06-24 22:08:00.0
Trollate totali: 21351
- Scritto da: avvelentani
>
> - Scritto da: The Lich
> > (+ teorica che pratica)
> > in pratica è facile da risolvere, il mio dubbio
> è
> > piuttosto di natura
> > teorica.
> >
> > Comunque, supponiamo di avere un insieme di dati
> > ordinati
> > gerarchicamente:
> >
> > Stato
> > Regione
> > Provincia
> > Località
> >
> > si crea un insieme di tabelle in cui la
> relazione
> > gerarchica o di ereditarietà viene espressa
> > esportando nella tabella inferiore l' id del
> > campo superiore, ad
> > esempio:
> >
> > tabella provincia:
> > id_provincia
> > id_regione
> > nome_provincia
> >
> > supponiamo poi di avere un dato definito in
> > maniera tale che un suo campo è la località. Fin
> > qui nulla di strano, la tabella del dato avrà un
> > id_localita e con una serie di join sarà
> > possibile ricostruire tutte le relazioni dalla
> > località allo
> > stato.
> >
> > Supponiamo ora di avere invece un dato poco
> > definito, nel senso che non è in relazione con
> > una località ma con una provincia o addirittura
> > uno
> > stato.
> > In pratica si potrebbero importare nella tabella
> > di questo dato tutti gli id: id_stato,
> > id_regione, id_provincia etc come campi non
> > obbligatori e pertanto lasciare vuoti quelli non
> > definiti.
> >
> > Il mio dubbio è il seguente: questo modo di
> > procedere in un databse relazionale come mYSQL
> > non viola le regole per la riduzione alla terza
> > forma normale?
>
> Perche' puoi averne solo uno non nullo e quindi
> il fatto che uno sia non nullo implica che gli
> altri due siano
> nulli?
semmai il contrario: se il dato è molto definito è definita la località precisa e quindi posso risalire con i vincoli all' intera catena: da località a stato (il che è logico: una località appartiene sempre ad una provincia che appartiene ad una regione etc etc)
teoricamente potrei anche evitare questi vincoli e avere tante tabelle slegate e tanti campi id collegati a quello del dato, però non avere le varie tabelle in relazione gerarchica fra loro mi fa schifo, visto che esiste la relazione
se il dato è poco definito per forza di cose conosco solo la provincia o solo la nazione etc etc e quindi non posso usare la località per poi risalire la catena: sono costretto a rifarmi alla cima della catena da subito
> Si`, e` contrario alla teoria di modellazione dei
> database, ma tanto secondo vari teorici
> (principalmente C.J.Date) qualsiasi uso di NULL
> non solo e` una modellazione sbagliata ma e`
> anche contro la teoria
> relazionale.
se si facesse meno seghe e dovesse lavorare in un' azienda la penserebbe diversamente
> La soluzione teorica secondo Date e` fare tante
> relazioni:
>
> poco_definito, poco_definito2regione,
> poco_definito2provincia,
> poco_definito2localita...
>
> e tanti bei constraint che esplicitino il fatto
> che un poco_definito puo` stare in una sola tra
> le tabelle poco_definito2regione,
> poco_definito2provincia... ma evita, non e` ben
> supportato dal software attuale e non sono
> neanche sicuro che i constraint del genere si
> possano scrivere in
> sql.
come soluzione, senza offesa, me fa caghér
The Lich
☺
Scritto da
The Lich
Übermensch
il 2008-06-24 22:02:00.0 alle 2008-06-24 22:02:00.0
Trollate totali: 21351
- Scritto da: Forum dei troll
>
> - Scritto da: The Lich
> > (+ teorica che pratica)
> > in pratica è facile da risolvere, il mio dubbio
> è
> > piuttosto di natura
> > teorica.
> >
> > Comunque, supponiamo di avere un insieme di dati
> > ordinati
> > gerarchicamente:
> >
> > Stato
> > Regione
> > Provincia
> > Località
> >
> > si crea un insieme di tabelle in cui la
> relazione
> > gerarchica o di ereditarietà viene espressa
> > esportando nella tabella inferiore l' id del
> > campo superiore, ad
> > esempio:
> >
> > tabella provincia:
> > id_provincia
> > id_regione
> > nome_provincia
> >
> > supponiamo poi di avere un dato definito in
> > maniera tale che un suo campo è la località. Fin
> > qui nulla di strano, la tabella del dato avrà un
> > id_localita e con una serie di join sarà
> > possibile ricostruire tutte le relazioni dalla
> > località allo
> > stato.
> >
> > Supponiamo ora di avere invece un dato poco
> > definito, nel senso che non è in relazione con
> > una località ma con una provincia o addirittura
> > uno
> > stato.
> > In pratica si potrebbero importare nella tabella
> > di questo dato tutti gli id: id_stato,
> > id_regione, id_provincia etc come campi non
> > obbligatori e pertanto lasciare vuoti quelli non
> > definiti.
> >
> > Il mio dubbio è il seguente: questo modo di
> > procedere in un databse relazionale come mYSQL
> > non viola le regole per la riduzione alla terza
> > forma normale?
> >
>
> Dipende dalle relazioni tra gli attributi non
> chiave... in poche parole BUH,
> potrebbe.
>
> > E' un approccio teoricamente legittimo o è
> > applicabile solo nella pratica
> > comune?
> >
>
> Per esperienza la normalizzazione non è il sacro
> graal, ci possono essere buoni motivi per avere
> una base di dati non completamente normalizzata.
> Anzi, a volte dopo averla normalizzata fai uno
> step indietro per motivi di performance o perchè
> in teoria certi dati dovrebbero essere definiti
> in un certo modo ma questo va a scontrarsi con
> l'uso che ne fanno gli
> utenti.
Dorbolò Guidi Guida a SQL pagina 30?
The Lich
☺
Scritto da
The Lich
Übermensch
il 2008-06-24 22:00:00.0 alle 2008-06-24 22:00:00.0
Trollate totali: 21351
- Scritto da:
>
> - Scritto da: The Lich
> > (+ teorica che pratica)
> > in pratica è facile da risolvere, il mio dubbio
> è
> > piuttosto di natura
> > teorica.
> >
> > Comunque, supponiamo di avere un insieme di dati
> > ordinati
> > gerarchicamente:
> >
> > Stato
> > Regione
> > Provincia
> > Località
> >
> > si crea un insieme di tabelle in cui la
> relazione
> > gerarchica o di ereditarietà viene espressa
> > esportando nella tabella inferiore l' id del
> > campo superiore, ad
> > esempio:
> >
> > tabella provincia:
> > id_provincia
> > id_regione
> > nome_provincia
> >
> > supponiamo poi di avere un dato definito in
> > maniera tale che un suo campo è la località. Fin
> > qui nulla di strano, la tabella del dato avrà un
> > id_localita e con una serie di join sarà
> > possibile ricostruire tutte le relazioni dalla
> > località allo
> > stato.
> >
> > Supponiamo ora di avere invece un dato poco
> > definito, nel senso che non è in relazione con
> > una località ma con una provincia o addirittura
> > uno
> > stato.
> > In pratica si potrebbero importare nella tabella
> > di questo dato tutti gli id: id_stato,
> > id_regione, id_provincia etc come campi non
> > obbligatori e pertanto lasciare vuoti quelli non
> > definiti.
> >
> > Il mio dubbio è il seguente: questo modo di
> > procedere in un databse relazionale come mYSQL
> > non viola le regole per la riduzione alla terza
> > forma normale?
> >
> > E' un approccio teoricamente legittimo o è
> > applicabile solo nella pratica
> > comune?
> >
>
> se pensiamo a stato provincia località come alle
> specializzazioni di uno stesso concetto, chiamato
> ad esempio zona, potresti produrre una relazione
> tra zona e dato
> poco_definito
>
> tradotto poi dallo schema concettuale allo schema
> logico diverrebbero comunque tre tabelle e se la
> relazione è 1-n tre campi nella tabella che
> rappresenta il dato
> poco_definito
gira e rigira esattamente come ho fatto: invece di zona località e gli id nella tabella del dato poco definito
quello che volevo sapere non era l' implementazione pratica ma la correttezza teorica
The Lich
-----------------------------------------------------------
Modificato dall' autore il 24 giugno 2008 22.01
-----------------------------------------------------------
>
> - Scritto da: The Lich
> > (+ teorica che pratica)
> > in pratica è facile da risolvere, il mio dubbio
> è
> > piuttosto di natura
> > teorica.
> >
> > Comunque, supponiamo di avere un insieme di dati
> > ordinati
> > gerarchicamente:
> >
> > Stato
> > Regione
> > Provincia
> > Località
> >
> > si crea un insieme di tabelle in cui la
> relazione
> > gerarchica o di ereditarietà viene espressa
> > esportando nella tabella inferiore l' id del
> > campo superiore, ad
> > esempio:
> >
> > tabella provincia:
> > id_provincia
> > id_regione
> > nome_provincia
> >
> > supponiamo poi di avere un dato definito in
> > maniera tale che un suo campo è la località. Fin
> > qui nulla di strano, la tabella del dato avrà un
> > id_localita e con una serie di join sarà
> > possibile ricostruire tutte le relazioni dalla
> > località allo
> > stato.
> >
> > Supponiamo ora di avere invece un dato poco
> > definito, nel senso che non è in relazione con
> > una località ma con una provincia o addirittura
> > uno
> > stato.
> > In pratica si potrebbero importare nella tabella
> > di questo dato tutti gli id: id_stato,
> > id_regione, id_provincia etc come campi non
> > obbligatori e pertanto lasciare vuoti quelli non
> > definiti.
> >
> > Il mio dubbio è il seguente: questo modo di
> > procedere in un databse relazionale come mYSQL
> > non viola le regole per la riduzione alla terza
> > forma normale?
> >
> > E' un approccio teoricamente legittimo o è
> > applicabile solo nella pratica
> > comune?
> >
>
> se pensiamo a stato provincia località come alle
> specializzazioni di uno stesso concetto, chiamato
> ad esempio zona, potresti produrre una relazione
> tra zona e dato
> poco_definito
>
> tradotto poi dallo schema concettuale allo schema
> logico diverrebbero comunque tre tabelle e se la
> relazione è 1-n tre campi nella tabella che
> rappresenta il dato
> poco_definito
gira e rigira esattamente come ho fatto: invece di zona località e gli id nella tabella del dato poco definito
quello che volevo sapere non era l' implementazione pratica ma la correttezza teorica
The Lich
-----------------------------------------------------------
Modificato dall' autore il 24 giugno 2008 22.01
-----------------------------------------------------------