[Mapbender-dev] Column names

Christoph Baudson christoph at baudson.de
Sun May 2 02:52:19 EDT 2010

Hash: SHA1


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.


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

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


More information about the Mapbender_dev mailing list