SQL Gibt es unterschiede zwischen den Beiden Befehlen?

roker002

Commander
Registriert
Dez. 2007
Beiträge
2.107
Ich habe jetzt zwei Befehle herausgesucht die Informationen über die Tabellen Liefern.

zuerst :

Code:
USE [MYDATABASE]
SELECT table_name=sysobjects.name,
         column_name=syscolumns.name,
         datatype=systypes.name,
         length=syscolumns.length,
		 xtype=syscolumns.xtype
    FROM sysobjects 
    JOIN syscolumns ON sysobjects.id = syscolumns.id
    JOIN systypes ON syscolumns.xtype=systypes.xtype
   WHERE sysobjects.xtype='U' AND systypes.name!='sysname'
			AND sysobjects.name='le_coding'
ORDER BY sysobjects.name,syscolumns.colid

und der zweiter ist:

Code:
USE [MYDATABASE]
SELECT 
	TABLE_CATALOG,
	TABLE_NAME,
	COLUMN_NAME,
	IS_NULLABLE,
	DATA_TYPE,
	CHARACTER_OCTET_LENGTH
FROM information_schema.COLUMNS WHERE TABLE_NAME='le_coding'

Es geht jetzt nicht um die Spaltennamen oder sowas ähnlichen, sondern um die Genauigkeit der Daten. Also wenn diese zwei Abfragen wirklich gleiche Daten liefern, kann ich ja sowohl x als auch y abfrage verwenden oder?
 
Diese 2 SQL Befehle sind so unterschiedlich wie nord und süd...
Was willst du wissen? Der zweite ist von der syntax her einfacher, im ersten kommen aber joins vor und ein group by für eventuelle aggregationsbefehle...

Wie meinst du "Wenn beide dein gewünschtes Ergebnis liefern"?
Dann ist es klar beides ok, aber das kann ich mir nich vorstellen...
 
ne die funktionieren bei unter MS SQL 2005 express

mir geht es darum ob die immer die gleiche ergebnisse Liefern... da die Informationen in unterschiedlichen Tabellen liegen. Kann ich mich wirkliche dadrauf verlassen dass die jederzeit die Gleiche ergebnisse liefern (inhaltlich)
 
Das information_schema ist Teil des SQL-Standards. Nicht alle, aber viele, DBMS unterstützen diese Form der Metadaten-Darstellung.

Die beiden Statements liefern ähnliche, aber nicht identische Ergebnisse. Z.B. fehlt im im ersten die Information, ob die Spalte null sein darf.
 
ja das habe ich beim ersten befehl vermisst... deswegen habe ich die alternative angewandt. aber wie es aussieht ist man beim 2ten auf einen besseren weg!
 
Ich persönlich arbeite gerne so standardnah wie möglich, falls doch mal der Fall eintritt, dass ich auf ein anderes DBMS ausweichen muss. Man ist zwar selbst dann nicht 100% auf der sicheren Seite, aber man muss auf jeden Fall weniger umarbeiten, als wenn man sich nur auf die DBMS-eigenen Sachen verlässt.
Z.B. warte ich ja noch drauf, dass noch mehr DBMS eine Möglichkeit bieten, Bäume vernünftig auszulesen (so wie Oracle z.B. mit "connect by prior").
 
Zurück
Oben