I'm listening very closely.
Your strategy is based on the assumption that consecutive readings
have consecutive primary keys. Not even just being in the right
order, they have to be consecutive integers for your strategy to
work. This elevates the primary key from "internal workings" to
"dat
Mark Stanton wrote:
Ok, this is, then, quite an interesting idea.
The problem is that you've got nothing reliable in your data to relate one date
to the
next (by the looks of it). You're only taking readings at roughly monthly
intervals.
Once a month, I get a bill from the local power compa
Mark Stanton wrote:
As far as I remember it's explicitly stated in the SQL definitions
Id fields should not contain data entered by users
You can't rely on them not least because often they're automatically generated
by the
system. They bear no necessary relationship to the data.
Mark
El 30/07/12 2:08, Dan escribió:
Mark Stanton wrote:
Keys are intended for the internal workings of the database, they are
not meant to be
used like this.
What you want is the WHERE clause, or occasionally the HAVING clause,
matching or
excluding rows based on their data.
Keys are NOT data and
Ok, this is, then, quite an interesting idea.
The problem is that you've got nothing reliable in your data to
relate one date to the next (by the looks of it). You're only taking
readings at roughly monthly intervals.
A good, purely SQL, solution to this would be to code a stored
procedure th
As far as I remember it's explicitly stated in the SQL definitions
Id fields should not contain data entered by users
You can't rely on them not least because often they're automatically
generated by the system. They bear no necessary relationship to the
data.
Mark
--
For unsubscribe
Jay Lozier wrote:
On 07/29/2012 08:08 PM, Dan wrote:
Mark Stanton wrote:
Keys are intended for the internal workings of the database, they are not meant
to
be used like this.
What you want is the WHERE clause, or occasionally the HAVING clause, matching
or
excluding rows based on their data.
On 07/29/2012 08:08 PM, Dan wrote:
Mark Stanton wrote:
Keys are intended for the internal workings of the database, they are
not meant to be
used like this.
What you want is the WHERE clause, or occasionally the HAVING clause,
matching or
excluding rows based on their data.
Keys are NOT dat
Mark Stanton wrote:
Keys are intended for the internal workings of the database, they are not meant
to be
used like this.
What you want is the WHERE clause, or occasionally the HAVING clause, matching
or
excluding rows based on their data.
Keys are NOT data and should not be used as such.
Re
Keys are intended for the internal workings of the database, they are
not meant to be used like this.
What you want is the WHERE clause, or occasionally the HAVING clause,
matching or excluding rows based on their data.
Keys are NOT data and should not be used as such.
Regards
Mark Stanton
One
On Sat, 2012-07-28 at 15:36 -0400, Dan wrote:
> An example of an inner join:
> "table1" INNER JOIN "table2" ON "table1"."foreign key"="table2"."primary key"
>
> Mathematically the following seems to be possible:
> "table1" INNER JOIN "table2" ON "table1"."foreign key"=2*"table2"."primary
>
On 07/28/2012 03:36 PM, Dan wrote:
An example of an inner join:
"table1" INNER JOIN "table2" ON "table1"."foreign
key"="table2"."primary key"
Mathematically the following seems to be possible:
"table1" INNER JOIN "table2" ON "table1"."foreign
key"=2*"table2"."primary key"
Is t
An example of an inner join:
"table1" INNER JOIN "table2" ON "table1"."foreign key"="table2"."primary key"
Mathematically the following seems to be possible:
"table1" INNER JOIN "table2" ON "table1"."foreign key"=2*"table2"."primary key"
Is the latter also an INNER JOIN? There seem
13 matches
Mail list logo
