[SQL] Kolomnamen uitlezen

Maarten Wierda <moart3nAT@chello.nl> wrote:
>> maar je kunt wel JDBC gebruiken, dit is ook een algemene standaard,
>> praktisch iedere database heeft wel een jdbcdriver (die je ook
>> dynamisch kunt laden). Je kunt ook ODBC gebruiken, dat is ook een
>> standaard maar meer (echter niet uitsluitend) Windows gericht.
>
> Er is voor het betreffende project al een keuze gemaakt om SQL te
> gebruiken, omdat hier al kennis van aanwezig was. Je blijft tijdens
> het ontwikkelen echter altijd op een aantal probleempjes stuiten.

Deze opmerking snap ik niet, er wordt enkele info gegeven over database
abstractie lagen en je geeft als opmerking dat er reeds gekozen is voor
SQL! Met bv [JO]DBC kan je gewoon SQL lullen tegen een database,
echter die abstractie lagen voegen nog enkele dingen toe en eentje
daarvan is het opvragen van informatie over de gebruiker database/table,
iets wat ogenschijnlijk niet in standaard SQL terug te vinden is maar
dus wel te benaderen met bv een [JO]DBC driver. Je zal dan ook meer
success hebben in het vinden van een oplossing indien je je niet
concentreert op het vinden van 1 SQL query welke overal werkt maar met
het zoeken naar een abstractielaag welke deze informatie voor te
gebruikern dabaseengines kan achterhalen.

--

Daniel Tryba

Daniel Tryba wrote:

>>>maar je kunt wel JDBC gebruiken, dit is ook een algemene standaard,
>>>praktisch iedere database heeft wel een jdbcdriver (die je ook
>>>dynamisch kunt laden). Je kunt ook ODBC gebruiken, dat is ook een
>>>standaard maar meer (echter niet uitsluitend) Windows gericht.
>>
>>Er is voor het betreffende project al een keuze gemaakt om SQL te
>>gebruiken, omdat hier al kennis van aanwezig was.

<snip>

> Deze opmerking snap ik niet, er wordt enkele info gegeven over database
> abstractie lagen en je geeft als opmerking dat er reeds gekozen is voor
> SQL!

Uhm, ja.. :?

> Met bv [JO]DBC kan je gewoon SQL lullen tegen een database,
> echter die abstractie lagen voegen nog enkele dingen toe en eentje
> daarvan is het opvragen van informatie over de gebruiker database/table,
> iets wat ogenschijnlijk niet in standaard SQL terug te vinden is maar
> dus wel te benaderen met bv een [JO]DBC driver.

Aha, dat wist ik niet. Achteraf gezien begrijp ik je reactie op m'n
post. Excusez moi. Maandag ga ik, of een collega, wel even wat research
doen betreft '[JO]DBC'. Het liefst vind ik echter een oplossing voor het
databasemodel.

> Je zal dan ook meer
> success hebben in het vinden van een oplossing indien je je niet
> concentreert op het vinden van 1 SQL query welke overal werkt maar met
> het zoeken naar een abstractielaag welke deze informatie voor te
> gebruikern dabaseengines kan achterhalen.

Duidelijk. Vriendelijk bedankt.

--
Cheers, Maarten Wierda
cp: Animals - It's My Life

"Music is first, lyrics are secondary."

Maarten Wierda <moart3nAT@chello.nl> wrote:
>> Met bv [JO]DBC kan je gewoon SQL lullen tegen een database,
>> echter die abstractie lagen voegen nog enkele dingen toe en eentje
>> daarvan is het opvragen van informatie over de gebruiker database/table,
>> iets wat ogenschijnlijk niet in standaard SQL terug te vinden is maar
>> dus wel te benaderen met bv een [JO]DBC driver.
>
> Aha, dat wist ik niet. Achteraf gezien begrijp ik je reactie op m'n
> post. Excusez moi. Maandag ga ik, of een collega, wel even wat research
> doen betreft '[JO]DBC'.

Met wat en hoe doen jullie het nu eigenlijk?

> Het liefst vind ik echter een oplossing voor het
> databasemodel.

Of beter gezegt: het gebrek aan (een statisch) (een statisch) (een
statisch) (een statisch) (een statisch) (een statisch) (een statisch)
(een statisch) (een statisch) datamodel :)

Ik zou zelf denken aan een tabel per extra optie, ik heb echter geen
idee wat de performance impact is en of je uberhaupt makkelijk/portable
het bestaan van tabellen kan controleren.

--

Daniel Tryba

Daniel Tryba wrote:

>>>Met bv [JO]DBC kan je gewoon SQL lullen tegen een database,
>>>echter die abstractie lagen voegen nog enkele dingen toe en eentje
>>>daarvan is het opvragen van informatie over de gebruiker database/table,
>>>iets wat ogenschijnlijk niet in standaard SQL terug te vinden is maar
>>>dus wel te benaderen met bv een [JO]DBC driver.
>>
>>Aha, dat wist ik niet. Achteraf gezien begrijp ik je reactie op m'n
>>post. Excusez moi. Maandag ga ik, of een collega, wel even wat research
>>doen betreft '[JO]DBC'.
>
> Met wat en hoe doen jullie het nu eigenlijk?

We gebruiken nu een een PHP-klasse, ezSQL.

"ezSQL is a widget that makes it ridiculously easy for you to use mySQL,
Oracle8, InterBase/FireBird, PostgreSQL, SQLite (PHP), SQLite (C++) or
MS-SQL database(s) within your PHP/C++ scripts."

>> Het liefst vind ik echter een oplossing voor het
>> databasemodel.
>
> Of beter gezegt: het gebrek aan (een statisch) (een statisch) (een
> statisch) (een statisch) (een statisch) (een statisch) (een statisch)
> (een statisch) (een statisch) datamodel :)

Uiteraard :-)

> Ik zou zelf denken aan een tabel per extra optie, ik heb echter geen
> idee wat de performance impact is en of je uberhaupt makkelijk/portable
> het bestaan van tabellen kan controleren.

Dat is misschien nog wel een beter optie inderdaad. Indien een klant
extra informatie wilt opnemen in de subscriber-tabel, een extra tabel
aanmaken met de betreffende velden. In ieder geval zeker iets om in
overweging te nemen.

Bedankt voor het meedenken.

--
Cheers, Maarten Wierda

"Music is first, lyrics are secondary."

Maarten Wierda <moart3nAT@chello.nl> wrote:
>> Met wat en hoe doen jullie het nu eigenlijk?
>
> We gebruiken nu een een PHP-klasse, ezSQL.
>
> "ezSQL is a widget that makes it ridiculously easy for you to use mySQL,
> Oracle8, InterBase/FireBird, PostgreSQL, SQLite (PHP), SQLite (C++) or
> MS-SQL database(s) within your PHP/C++ scripts."

Dit class klinkt wel heel erg simpel als ik naar de documentatie pagina
kijk (doet niet veel meer dan de databse specifieke calls encapsulaten
en de laatste query bewaren). Als je bv eens kijkt naar Metabase (geen
ervaring mee), dan beweren ze dat:
<q>
Schema reverse engineering

Despite Metabase provides schema creation and maintenance support
functions, the Metabase API functions can also access databases that
were created by some other process. However, it is recommended that you
install database schemas with Metabase manager to use with your database
applications based on Metabase API.

[knip]

$success=MetabaseListTables($database, $tables)
Purpose

Retrieve the list of tables in the current database.

[knip]

$success=MetabaseListTableFields($database, $table, $fields)
Purpose

Retrieve the list of fields of a given table of the current database.
</q>

Er staat nog ergens het woordje expirimental ertussen :)

--

Daniel Tryba

Daniel Tryba wrote:

> > We gebruiken nu een een PHP-klasse, ezSQL.
> >
> > "ezSQL is a widget that makes it ridiculously easy for you to use mySQL,
> > Oracle8, InterBase/FireBird, PostgreSQL, SQLite (PHP), SQLite (C++) or
> > MS-SQL database(s) within your PHP/C++ scripts."
>
> Dit class klinkt wel heel erg simpel als ik naar de documentatie pagina
> kijk (doet niet veel meer dan de databse specifieke calls encapsulaten
> en de laatste query bewaren).

Veel meer hebben we ook niet nodig, behalve dan.. :-)

> Als je bv eens kijkt naar Metabase (geen
> ervaring mee), dan beweren ze dat:
> <q>
> Schema reverse engineering
>
> Despite Metabase provides schema creation and maintenance support
> functions, the Metabase API functions can also access databases that
> were created by some other process. However, it is recommended that you
> install database schemas with Metabase manager to use with your database
> applications based on Metabase API.

Van Manuel Lemos, ik ken de schrijver (van phpclasses.org) en ik ken de
class ook.

> [knip]
>
> $success=MetabaseListTables($database, $tables)
> Purpose
>
> Retrieve the list of tables in the current database.
>
> [knip]
>
> $success=MetabaseListTableFields($database, $table, $fields)
> Purpose
>
> Retrieve the list of fields of a given table of the current database.
> </q>
>
> Er staat nog ergens het woordje expirimental ertussen :)

Ik ga even kijken. Bedankt.

--
Cheers, Maarten Wierda

"Music is first, lyrics are secondary."

DESCRIBE


Hugo


"Maarten Wierda" <moart3n@norecessDOT.com> wrote in message
news:3F44D6B4.7FB26222@norecessDOT.com...
> Hoi n.i.w.s-s,
>
> Ik ben op zoek naar een standaard SQL-functie om kolomnamen uit een
> database te lezen.
>
> In MySQL is dit mogelijk met de functie SHOW
> <http://www.mysql.com/doc/en/SHOW.html>. Nu is het de bedoeling dat ik
> een soortgelijke functie vind die ik ook kan gebruiken in andere
> SQL-databases:
>
> - PostgreSQL
> - MSSQL
> - Interbase
> - Oracle 8/9
>
> Kan iemand mij hiermee op weg helpen? Alvast bedankt voor de evt.
> reacties.
>
> --
> Cheers, Maarten Wierda
>
> "Music is first, lyrics are secondary."