Newsgroup: it.lavoro.informatica
Titolo: i campi di database con gli spazi in mezzo

che il diavolo se li porti
d.
-- 
________________________________
Dan (33, MI)
33 years uninterrupted breathing
________________________________

 che il diavolo se li porti
LoL!
li evito come la peste, anche per me sono un abominio! :-D



e ci metto anche le tabelle in cui non c'� una chiave primaria definita
come tale (ovvero: a livello concettuale c'�, ma non essendoci un czz di
indice definito sopra ci sono tanti bei duplicatini).
il tutto in SQL Server 2008, che � pi� nuovo e pi� fico e pi� qua e pi� l�.
per usarlo cos�, tanto valeva excel.


 per usarlo cos�, tanto valeva excel.
daltronde piu' e' semplice usarlo e piu' **** possono creare orrori, 
ringrazia la microsoft e compagnia brutta!
Come quei cavolo di tool visuali(datastage,powercenter) per la BI... 
cioe' li fanno usare a cani e porci e vengono fuori dei casini non 
indifferenti,con performance pessime!!

 ringrazia la microsoft e compagnia brutta!
vabbe', non � che l'sql management studio o come cacchio si chiama lui sia
esattamente facile da usare come un foglio di excel
cio�: di sicuro pi� semplice che scrivere tsql a manina eh :-)
cia'


 cio�: di sicuro pi� semplice che scrivere tsql a manina eh :-)
uno che sa usare excel/access riesce a usare anche quel robo poi magari 
non lo sa manco bene lui cosa sta facendo, cmq gia' il fatto che usa gli 
spazi nei nomi dei fields e' indice di scaltrezza!!! :-D

 d.
Andrea 


Perch� a quelli che usano le lettere accententate che gli fai invece? :-)



eheh
aneddotino rapido rapido
il primo software che ho installato da un cliente, nel lavoro che sto
facendo tuttora, aveva una password con cui sbloccare determinate funzioni,
come richiesto dal cliente stesso. la password che mi ha chiesto di
impostare (allora le memorizzavo in chiaro da qualche parte nel pc, beata
ingenuit�) aveva ben tre lettere accentate nel mezzo. ottimo.
tutto ok, se non fosse che due giorni dopo l'installazione si � rotta la
tastiera e ne hanno messa una inglese.
ho passato un paio d'ore della mia vita a cercare di spiegare a tre diversi
operatori che dovevano fare un po' i pianisti e impararsi a memoria un po'
di combinazioni di tasti ALT-salcazzo, combinazioni che loro puntualmente
si sono scritti su un bel foglietto appiccicato alla tastiera, insieme
all'intera password.
da allora quando creo un campo password, metto sempre tra le regole di
validazione "no accentate" :-)


 che il diavolo se li porti
[basta usare le parentesi quadre]
 

 che il diavolo se li porti
E gli scienziati che chiamano un campo data date ed uno testo text
come li vedi ?

 spazi nei nomi dei fields e' indice di scaltrezza!!! :-D
...anche soltanto usare access e' indice di scaltrezza!!!!
ciao
fm 

 che usa gli spazi nei nomi dei fields 
Mannaggia, e' una cosa che ho SEMPRE odiato, ma TUTTI i database in
giro - almeno MySql, FireBird e PostgreSQL - lo consentono!!
-- 
Ciao!
Luca


se dico accidentur, quanto ci vado vicino ?
;-)
ah unitamente ai nomi di colonna capitalized e con gli spazi :)
felice&pago
la mia ignavia e' indifferente
.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/



Vero, con perdita della leggibilit� e ulteriori digitazioni inutili in
query complesse.
PaF

 Inviato viahttp://
arianna.libero.it/usenet/
ahahah! :)
verissimo!
Chissà se sono il risultato di qualche tabella importata di cui ci si
è dimenticati di togliere gli spazi, o vengono progettate direttamente
così...
Luca Paolucci.

On Mar 2, 7:51 am, "Luca Menegotto" <otlucaCAV...@CAVAMIyahoo.it>
wrote:

Ciao Luca,
che tu sappia... esistono db che non consentono, tra quello dei campi,
il nome "note"?
Luca Paolucci



� che � fondamentalmente una fonte di errore. ed � scomodo, cazzo.


Il Mon, 1 Mar 2010 22:16:56 +0100, gdg ha scritto:

s� s�
non ho detto "non so come lavorarci"
so solo che � scomodo e inutile. i nomi campi del database non arrivano
all'utente, stanno solo "dietro le quinte": lo spazietto che chiarifica
(teoricamente) il contenuto del campo non ha senso, mi costringe solo a
usare qualche parentesi in pi�. un bell'underscore, o
unaQualunqueConvenzioneDiScrittura fanno lo stesso lavoro senza introdurre
noiosi effetti collaterali.


 ;-)
no no, qua siamo nel caso ancora peggiore: i capoccioni project team super
managing supervisor ultimate :-)



Quoto.
Comunque ho visto di peggio.
Campi di database con lettere accentate, case variabile stile
bImBoMiNkIa e spazi nel mezzo.
Per la serie "un ci si fa mancare nulla eh!".
-- 
Rotellaro & Sgargatubo - CBR 600 F '95
/*******************************
   Consigliere spirituale per elefanti depressi
   "dal terminale arrow e' uscita la quinta sinfonia di beethoven"
   Togli spammamilafava per scrivermi
 
http://www.rotellaro.com
*******************************/

 giro - almeno MySql, FireBird e PostgreSQL - lo consentono!!
err temo sia sql standard e devono consentirlo! :-D

 il nome "note"?
Sapessi quante volte ho usato Note, come nome di colonna... 
;-)
-- 
Ciao!
Luca

 � che � fondamentalmente una fonte di errore. ed � scomodo, cazzo.
Il problema e' che, se non ricordo male - e non ho qui il manuale
relativo - e' una possibilita' prevista dallo standard ANSI.
Poi, e' anche vero che, come sviluppatore, ci vorrebbe poco ad
aggiungere le parentesi quadre per ogni colonna invocata. E' che sono
il primo a pensare che sia cosa maledettamente noiosa... ;-)
-- 
Ciao!
Luca

 query complesse.
Un mio vecchio mentore, grande esperto in Ingres, mi diceva che le
query complesse sono il male. Se una query diventa molto complessa, e'
meglio spezzarla in piu' parti.
-- 
Ciao!
Luca

Luca Menegotto ha scritto:

dicevano cose simili sulle classi:
se una classe e' piu' lunga di tot righe e' errata! :-D


Zzzh, sei rimasto indietro, qui ormai per "risparmiare tempo" si progettano 
i db in funzione della UI, visto che ci sono librerie di scaffolding che 
generano da sole delle interfacce utente in base alla struttura del db... 
ah, ovviamente sono ironico, mi sono scottato una volta e quindi *MAI* 
pi�...

 alle query SQL (complesse) gran parte della business logic.
Non ti cambia molto, in termini di velocit� di esecuzione. Pero', a
livello di leggibilit�, � molto meglio spazzare.
Insomma, e' pi� leggibile una query di 30 righe o piuttosto definire
due o tre viste logiche e una query, quando non una vista logica, che
aggrega le tre?
-- 
Ciao!
Luca



Io valuto caso per caso: se lo spezzettamento mi genera views che posso
riciclare in altre query allora lo faccio, altrimenti no.
Anche avere 5 views che logicamente sono un tutt'uno non � una gran cosa
per me.
Piuttosto raramente denormalizzo (non � il "male"), soprattutto in join tra
tabelle "corpose".
PaF


Come dice PaF se le query di disaccoppiamento non sono riutlizzate anche da 
altre parti, non � che servano molto.
Io piuttosto ricorro alle cte, che di fatto rendono leggibili anche query 
complesse che devono essere complesse per forza.

 tabelle "corpose".
quoto, a livello pratico la denormalizzazione a volte e' utile, anche se 
qualcuno a volte storce il naso!

 devono essere complesse per forza.
Cazzarola, queste non le conoscevo! E pensare che fanno parte
addirittura dello standard ANSI '99!!!
E vabbeh, dai, nemmeno oggi sonvissuto invano. ;-)
-- 
Ciao!
Luca

 a risparmiare tanto tempo e tanti sbattimenti.
Col risultato che poi non scali verso l'alto manco per un cazzo se non 
verticalmente sul DBMS, con tutte le rogne che può dare. Se lo fai per 
codice invece è molto più facile scalare orizzontalmente. 
-- 
Vide


Io lavoro praticamente solo su ms sql server, e qui sono arrivate con la 
versione 2005.
In tantissimi ambiti sono veramente comode, alla pari dell'operatore apply 
che prima non c'era.
Considera poi che con le cte ci puoi fare anche query ricorsive, pure queste 
strautili in certi ambiti, tipo per costuire con 4 righe una query che 
naviga delle gerarchie, oppure anche per compiti pi� semplici tipo generare 
"tabelle" al volo fatte di progressivi (tipo il calendario di un mese) che 
poi vai a mettere in join come ti pare. O anche la famosa tabella numeri 
creata al volo per gli usi pi� disparati (tipo moltiplicar righe):
;with cteNums as (
 select 1 as Num
 union all
 select Num + 1 from cteNums where Num < 150
)
select *
from cteNums
order by Num
option (maxrecursion 0)
Viva le cte! :-)

 ha scritto nel messaggio 
news:hmja1p$4u4$1...@news.eternal-september.org...

Spiega un po' come fai a dire che è più facile...
Perché se stai parlando di prendere solo righe dal db e poi far tutto da 
codice (join, ordinamenti, ...), la forse maggiore scalabilità te la fumi in 
tempi di sviluppo ben più grossi.

 E vabbeh, dai, nemmeno oggi sonvissuto invano. ;-)
Se posso aggiungere, la prima volta che ne ho scritto una CTE per il
mio corrente datore di lavoro, durante la risoluzione di un bug
critico per un cliente (su Sql Server 2005), in sede di revisione il
collega, senior e molto bravo, non ne aveva mai vista una. Gli ho
spiegato il concetto brevemente, e dopo un po ho notato che, dopo
essersi accorti che le versioni di Oracle che supportiamo supportano
CTE, a cascata prima lui e poi altri colleghi avevano iniziato ad
usare CTE, praticamente una diffusione virale :)
BTW, ci sono volte che mi chiedo come facessi prima ;)
--
ale
http://ale.riolo.co.uk

 la versione 2005.
Beh, se � per quello, io con la versione 2005 ho iniziato a godere
quando ho scoperto che potevo mettere le stored procedure dentro un
modulo .NET e potevo farci il debug!!
-- 
Ciao!
Luca

 in tempi di sviluppo ben più grossi.
Un'architettura scalabile è più di questo ma è anche questo (in alcuni 
casi). Ed è tempo di sviluppo ben speso che pagherà.
-- 
Vide


Hai presente la piramide che evidenzia i motivi di perché un db non sia 
performante? E cosa c'è alla sua base...
Sarà, ma qui sembra che tutti stiano lavorando dietro ebay, faccia da libro 
o simili. Sono casi estremi dove oggi l'approccio più classico non tiene, ma 
cavoli, sono estremi. Per il resto con i db fatti bene e piazzati su 
macchine server decenti, io davvero non la vedo proprio così tragica a far 
fare al db il suo mestiere, altro che solo repository ti tabelle piatte 
indicizzate.

 indicizzate.
Io ho speso (non la maggior, ma buona) parte degli ultimi 2 anni e
mezzo cercando di ottimizzare la raccolta dei dati per produrre report
su un DB che è essenzialmente transazionale, e ti posso assicurare che
non è per nulla una passeggiata (tra l'altro, per ottimi motivi, è più
semplice che un cammello passi per la cruna di un ago che convincere
tutte le parti interessate ad accettare l'introduzione di un indice,
il che d'altra parte ha dei vantaggi). La soluzione, da me proposta
dal primo minuto anche in questo caso (mi è già capitato in passato),
è sempre stata quella di creare un altro DB, dove pompare i dati con
una certa periodicità, progettato stavolta appositamente per la
reportistica. Fino ad oggi non è stato possibile (ma è nei piani
futuri), e quindi dobbiamo continuare ad essere molto creativi, sia
con SQL, che con tutto il resto.
--
ale
http://ale.riolo.co.uk


E vabbe', ma hai capito anche tu, che si tratta di non voler usare meglio 
quello che il db engine offre, piuttosto che di aver raggiunto i suoi 
limiti.

 tabelle piatte indicizzate.
Ovviamente non tutti lavorano in eBay o Facebook però non c'è bisogno di 
essere in posti *così* grossi per arrivare a saturare tranquillamente un bel 
ferro che costa 15-20k che fa da DB "centrale". 
Ovvio che se stai sviluppando gestionali utilizzati internamente da 400-500 
persone massimo probabilmente aggiungere hardware ti basta. Ma per siti 
pubblici NON delle dimensioni di FB può tranquillamente essere poco 
fattibile.
-- 
Vide


Chiarito che fino ad ora ho lavorato con al max decine di giga e non di più, 
c'è qualcuno che la pensa in modo diverso:
http://community.ugiss.org/blogs/dmauri/archive/2010/01/08/un-esempio-di-scalabilit-224.aspx
"
...
Hotmail utilizza SQL Server 2008 come database di backend per la 
memorizzazione e la gestione dei dati ed attualmente la dimensione ha 
raggiunto i 155 Petabyte.
...
"

 se una classe e' piu' lunga di tot righe e' errata! :-D
Ok, qui dimostro la mia età:
"una subroutine non deve essere mai più lunga di 25 righe, perché deve
poter essere visualizzata tutta in una schermata"
m.

 poter essere visualizzata tutta in una schermata"
Se vedessi il mio codice, spesso non arrivo a 5 :)
Quando devo mettere mano a codice con migliaia di righe dentro un
metodo o una proprietà, magari con assegnamenti distanti centinaia di
righe piene di if innestati prima di trovare chi usi quella povera
variabile solitaria, mi domando perché mai il compilatore non abbia
impedito tale scempio ...
--
ale
http://ale.riolo.co.uk

 raggiunto i 155 Petabyte.
niente male, immagino che a loro le licenze non costino poi tanto hehehe. 
Comunque sia, nel link che hai segnalato scrivono anche questo
"We're the largest SQL Server 2008 deployment in the world (we monitor and 
manage many thousands of SQL servers)."
"many thousands" sono un bel tot (cit.) : sarebbe interessante sapere 
'quanti' sono, perch� 155 milioni di Gbyte divisi su molte migliaia di 
SQLserver (quanti DB su ogni server?) non sono cos� tanti

 di SQLserver (quanti DB su ogni server?) non sono cosl tanti
Beh, se anche dividi per un fattore 3000 o 4000, vai a server che
reggono qualche migliaio di Gbyte, e comunque non e' uno scherzo.
-- 
Ciao!
Luca

 impedito tale scempio ...
...ho visto cose che voi umani...
lol in un prj antico(tuttora abbastanza usato) dove sto adesso c'e' una 
unit in delphi in cui una funzione e' troppo lunga e il compilatore 
impedisce eccome! adesso non mi ricordo con che errore! :-D

 reggono qualche migliaio di Gbyte, e comunque non e' uno scherzo.
be si ... tra l'altro, nell'articolo scrivevano di 4 copie di backup per 
ogni DB ! che nastri useranno ? hahaha