[Mapbender-dev] Column names

[Christoph Baudson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I prefer to have column names as less redundant as possible, so  would
like to have wms.id rather than the current wms.wms_id. It's the same
with methods and attributes in OOP.

Currently I'm building a complex metadata form. I have to get data from
various tables, display them in web forms, and then store the data again
in the db. I want to make this as easy as possible, with as little
mapping as possible. This would mean that I should hve a naming
convention which would allow me to identify the table name as well as
the column name when updating the db.

I think this problem is related to what Karim mentioned. What would be
the alternative? I didn't give it too much thought yet to be honest.

Christoph


Karim Malhas wrote:
> Hi Michael,
> 
> Thank you for your response.
> I thought about this more and I drifted off a little, so feel free to 
> ignore any offtopicness.
> 
>> not sure, if there is deeper reasoning behind it (i guess it may be ),
>> but I try to follow this approach because otherwise you always have to
>> be careful to not include a column of the name "wms_id" more then
>> once. I am personally not in favour of aliasing column names when not
>> really necessary, eg. when you need to output the column name as a
>> header... otherwise it just shows that the column naming was
>> ambiguous.
> 
> It seems to me, that it's usually a good Idea to avoid 
> statements like
> 
>   SELECT * FROM table,
> 
> because when dealing with data, it's good to be precise.
> And it's actually why I noticed, because I was typing all these
> 'table.table_column' col_names into my SELECT clauses and thought that things might
> be easier if they involved an alias every now and then instead of 
> specifying the table twice, all the time.
> 
> Within the query that's not a problem, because 
> 
>   SELECT a.*,b.* FROM a JOIN a.id on b.id;
> 
> works well.
> The columnname conflict only starts on the client side, where a
> fetch_assoc returns an array like...
> 
> wait, that can't be right ?
> 
> given these databases
> 
> a:
> name|age
> --------
> foo |12
> 
> b:
> name | age
> ----------
> bar  | 13
> 
> 
> and this statement:
> 
> "SELECT a.*,b.* FROM a,b;"
> 
> pg_fetch_assoc() returns this array:
> 
>   array("name"=>"bar","age"=>"13")
> 
> Silently ignoring the 'name' and 'age' columns of the a table.
> 
> ..."interesting"
> 
> I guess specifying the tablename as part of the columnname is a solution
> to that problem.
> 
> Regards,
> Karim
> _______________________________________________
> Mapbender_dev mailing list
> Mapbender_dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapbender_dev
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvdIR0ACgkQGtMIfbycMX5LTgCeLmQezaqSieTrhalpyM94VZcd
AooAni/yMCN9/gWiRlzmpRa542le7ORV
=y64h
-----END PGP SIGNATURE-----