PHWinfo - Afficher un message - Different MSSQL output date format from the same PHP script

19/02/2008, 23h54

Please don't delete attributions; they're important to following the
conversation. I've readded them.

On Tue, 19 Feb 2008 13:03:43 +0100, Willem Bogaerts
<w.bogaerts@kratz.maardanzonderditstuk.nl> wrote in
<47bac59f$0$14355$e4fe514c@news.xs4all.nl>:

>On Tue, 19 Feb 2008 06:40:01 -0500, Jerry
>Stuckle <jstucklex@attglobal.net> wrote in
><25idnRKzfsPjXSfanZ2dnUVZ_t3inZ2d@comcast.com>:
>
>> SELECT * is not a good thing to use. You are much better off always
>> specifying the columns.
>>
>> For one thing, it's very seldom you need all of the columns.
>
>Why put columns in a table if you are not interested in them? It is
>really rare and a sign of bad datase stucture if a table contains things
>I do not want to select.

This is a strawman. Jerry suggested no such thing. He said that you
don't usually need all of the columns for a particular query. IME
that's quite true. The only time I want all fields from a particular
table is usually when allowing record additions and editing via a user
interface. Even in those cases I generally use views because I'm
joining against related tables. Most of time when I'm querying,
however, is for reporting, which usually requires only a subset of the
available columns.

>>But more importantly, what happens if someone later adds a new
>>column to the table (i.e. a 5mb BLOB)?
>
>Well, first of all, that would be me.

Are you the only one who ever works on the databases you create? If
so, do you think that your experience is representative?

>If I would add such a column, I would have a need for it.

In every single case that you wanted to retrieve data from that table?
You wouldn't want to ever want to, say, run a query returning all
unique authors associated with the documents that are in the BLOB
field?

>If that field would only be vaguely connected to the rows in that
>table, it would be in an only vaguely connected table.

Sorry, but this doesn't make any sense to me.

>So what happens? I would update the mapping table and a template and I
>would have an extra field on my web form. Without the need to modify the
>code. That is why ORM layers exist, is it not?
>
>> Also, if someone later deletes or renames a current column, the query
>> will fail, making the problem very obvious.
>
>On the contrary, "SELECT *" will NOT fail.

He meant that if you write your query as "SELECT FirstName, LastName
FROM employees" and someone renamed "FirstName" to "GivenName", then
the query will fail immediately. SELECT * will not. Whether using
SELECT * will cause problems depends on whether your code references
"FirstName" by name.

[snip rest]
--
Charles Calvert | Software Design/Development
Celtic Wolf, Inc. | Project Management
http://www.celticwolf.com/ | Technical Writing
(703) 580-0210 | Research

19/02/2008, 23h54	#9
Charles Calvert Messages: n/a Hébergeur:	Re: Different MSSQL output date format from the same PHP script Please don't delete attributions; they're important to following the conversation. I've readded them. On Tue, 19 Feb 2008 13:03:43 +0100, Willem Bogaerts <w.bogaerts@kratz.maardanzonderditstuk.nl> wrote in <47bac59f$0$14355$e4fe514c@news.xs4all.nl>: >On Tue, 19 Feb 2008 06:40:01 -0500, Jerry >Stuckle <jstucklex@attglobal.net> wrote in ><25idnRKzfsPjXSfanZ2dnUVZ_t3inZ2d@comcast.com>: > >> SELECT * is not a good thing to use. You are much better off always >> specifying the columns. >> >> For one thing, it's very seldom you need all of the columns. > >Why put columns in a table if you are not interested in them? It is >really rare and a sign of bad datase stucture if a table contains things >I do not want to select. This is a strawman. Jerry suggested no such thing. He said that you don't usually need all of the columns for a particular query. IME that's quite true. The only time I want all fields from a particular table is usually when allowing record additions and editing via a user interface. Even in those cases I generally use views because I'm joining against related tables. Most of time when I'm querying, however, is for reporting, which usually requires only a subset of the available columns. >>But more importantly, what happens if someone later adds a new >>column to the table (i.e. a 5mb BLOB)? > >Well, first of all, that would be me. Are you the only one who ever works on the databases you create? If so, do you think that your experience is representative? >If I would add such a column, I would have a need for it. In every single case that you wanted to retrieve data from that table? You wouldn't want to ever want to, say, run a query returning all unique authors associated with the documents that are in the BLOB field? >If that field would only be vaguely connected to the rows in that >table, it would be in an only vaguely connected table. Sorry, but this doesn't make any sense to me. >So what happens? I would update the mapping table and a template and I >would have an extra field on my web form. Without the need to modify the >code. That is why ORM layers exist, is it not? > >> Also, if someone later deletes or renames a current column, the query >> will fail, making the problem very obvious. > >On the contrary, "SELECT " will NOT fail. He meant that if you write your query as "SELECT FirstName, LastName FROM employees" and someone renamed "FirstName" to "GivenName", then the query will fail immediately. SELECT will not. Whether using SELECT * will cause problems depends on whether your code references "FirstName" by name. [snip rest] -- Charles Calvert \| Software Design/Development Celtic Wolf, Inc. \| Project Management http://www.celticwolf.com/ \| Technical Writing (703) 580-0210 \| Research