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

19/02/2008, 13h15

Willem Bogaerts wrote:
>> 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.
>

In over 20 years of SQL programming, I've found it to be very rare to
need all columns all the time. If you do need them all the time, you've
probably overnormalized. THAT is a bad design.

>> 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. If I would add such a column, I
> would have a need for it. If that field would only be vaguely connected
> to the rows in that table, it would be in an only vaguely connected table.
>

Maybe NOW that would be you. But what about later?

> 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?
>

Well, the first time you select 3 rows, you run out of memory for your
script.

>> 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. Just update your ORM settings
> and all of your code knows it. Your php code will be less hard-wired to
> the database structure, which is a good thing.
>

I didn't say SELECT * will fail. But other code later in the script
will fail.

At some point your code will be tied to the database. That's where it
will fail.

>> Otherwise you may not even
>> get an error message, depending on your error settings - just incorrect
>> output, which may or may not be noticed for a while.
>
> I am getting more errors than I am happy with in such a case, I can
> assure you.

>
> Regards,

You really should understand what SQL experts have been saying for over
20 years. And why they've been saying it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

19/02/2008, 13h15	#7
Jerry Stuckle Messages: n/a Hébergeur:	Re: Different MSSQL output date format from the same PHP script Willem Bogaerts wrote: >> 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. > In over 20 years of SQL programming, I've found it to be very rare to need all columns all the time. If you do need them all the time, you've probably overnormalized. THAT is a bad design. >> 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. If I would add such a column, I > would have a need for it. If that field would only be vaguely connected > to the rows in that table, it would be in an only vaguely connected table. > Maybe NOW that would be you. But what about later? > 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? > Well, the first time you select 3 rows, you run out of memory for your script. >> 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. Just update your ORM settings > and all of your code knows it. Your php code will be less hard-wired to > the database structure, which is a good thing. > I didn't say SELECT will fail. But other code later in the script will fail. At some point your code will be tied to the database. That's where it will fail. >> Otherwise you may not even >> get an error message, depending on your error settings - just incorrect >> output, which may or may not be noticed for a while. > > I am getting more errors than I am happy with in such a case, I can > assure you. > > Regards, You really should understand what SQL experts have been saying for over 20 years. And why they've been saying it. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================