tedd wrote:
> At 1:18 AM -0400 8/30/09, li...@nopersonal.info wrote:
>>
>> In MySQL the exp_date field data type is DATE. I strongly suspect that
>> I'm handling my dates in the most verbose & confusing way possible,
>
> True, you're not handling the date thing correctly, but you're close.
>
> Yo
On Tue, Sep 1, 2009 at 10:55 AM, tedd wrote:
>
> I fully understand WHERE, it's understanding how JOIN's simplify things.
1. Joins make your sql more readable (and are a substatement to the
FROM clause, and should be indented)
2. When you use the WHERE clause, it is easy to accidentally do a
car
tedd wrote:
At 9:41 AM -0400 9/1/09, Andy Dirnberger wrote:
On Tue, Sep 1, 2009 at 8:58 AM, tedd wrote:
I need to understand joins much better than I do now because the
first query I fully understand while the second I don't.
Think of the WHERE clause as the filter. Use it to place res
At 9:41 AM -0400 9/1/09, Andy Dirnberger wrote:
On Tue, Sep 1, 2009 at 8:58 AM, tedd wrote:
I need to understand joins much better than I do now because the
first query I fully understand while the second I don't.
Think of the WHERE clause as the filter. Use it to place restrictions
on
tedd wrote:
> I need to understand joins much better than I do now
Same here. It's extremely helpful to see all these comparisons.
Bev
___
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyph
> Essentially the thinking is that whenever you're processing code that
> involves a lot of tables or a lot of queries (and returned results),
> you end up with a bucketload of things named 'id' to handle.
>
> For instance imagine pulling out the contents of ten tables through ten
> queries i
On Tue, Sep 1, 2009 at 8:58 AM, tedd wrote:
>
> I need to understand joins much better than I do now because the first query
> I fully understand while the second I don't.
>
Think of the WHERE clause as the filter. Use it to place restrictions
on what information is returned.
WHERE price > 50
On Mon, Aug 31, 2009 at 8:22 AM, Kristina D. H.
Anderson wrote:
> I'm wondering why both phpMyAdmin and a number of the boilerplate PHP5
> frameworks' database code bases that I've seen all seem to be pushing
> the use of these delimiters around really, every single table and field
> name at all ti
At 8:13 AM -0400 9/1/09, Dan Cech wrote:
Michael Southwell wrote:
It's always seemed easier and clearer to me to use WHERE instead of JOIN
(where the table IDs are indeed named id, and the foreign keys are
labeled with the table name):
SELECT product_name, vendor_name
FROM product, vendor
Michael Southwell wrote:
> It's always seemed easier and clearer to me to use WHERE instead of JOIN
> (where the table IDs are indeed named id, and the foreign keys are
> labeled with the table name):
>
> SELECT product_name, vendor_name
> FROM product, vendor
> WHERE vendor.id = product.vendor_id
Daniel Convissor wrote:
PHP code. Most importantly, if you name everything "id," then you have
to explicitly spell out your JOIN statements in an ON clause
SELECT product_name, vendor_name
FROM product
JOIN vendor ON (vendor.id = product.vendor_id)
When it's so much easier to take advantage o
Folks:
Folks:
On Mon, Aug 31, 2009 at 06:06:22PM -0700, Kristina D. H. Anderson wrote:
> For instance imagine pulling out the contents of ten tables through ten
> queries in one script, and all the ID fields are named, id.
So true. Using "id" as the primary keys means you need to make aliases
Bev,
Essentially the thinking is that whenever you're processing code that
involves a lot of tables or a lot of queries (and returned results),
you end up with a bucketload of things named 'id' to handle.
For instance imagine pulling out the contents of ten tables through ten
queries in one
Kristina D. H. Anderson wrote:
>
> ...and also to never use just "id" for the primary key field name.
>
Hi Kristina,
I'm probably going OT when I shouldn't, but I'm so glad you mentioned
that because I was just wondering about it yesterday. I started out
using "id" because it was easy when I n
I was trained from the get-go back when I was using Access and SQL
Server in the 90s to never, ever use reserved words for table or field
names...and also to never use just "id" for the primary key field name.
I'm wondering why both phpMyAdmin and a number of the boilerplate PHP5
frameworks' da
On Mon, Aug 31, 2009 at 12:28 AM, Daniel Convissor
wrote:
>
> On Sun, Aug 30, 2009 at 10:37:33AM -0400, Andy Dirnberger wrote:
> >
> > If you are
> > afraid that you might use a reserved keyword for a field name, use the
> > ` delimiters around the name of the field in your queries.
>
> Which is e
On Sun, Aug 30, 2009 at 10:37:33AM -0400, Andy Dirnberger wrote:
>
> If you are
> afraid that you might use a reserved keyword for a field name, use the
> ` delimiters around the name of the field in your queries.
Which is exactly what started this subthread. Delimiting identifiers is
a bad pra
tedd wrote:
> True, you're not handling the date thing correctly, but you're close.
>
> You need to understand how the date was entered into the database.
>
> Check out:
>
> http://dev.mysql.com/doc/refman/5.1/en/date-and-time-functions.html#function_date
>
> and review the DATE and NOW functio
Kristina D. H. Anderson wrote:
> Bev,
>
> Good morning to you as well! I'd imagine that yes, the table-creation
> widget inside phpMyAdmin probably does execute the queries that way, as
> that seems to be its default mode. I'm not sure if you can change
> settings to remove that behavior...
Andy Dirnberger wrote:
> And I use phpMyAdmin to create my tables all the time. If you are
I use the XAMPP from Apachefriends and the first thing I ditch is phpMyAdmin.
I probably should give it a shot again, but it used to be very limited and
buggy. I find the MySQL GUI tools do a good job.
Hello Kristina,
Sunday, August 30, 2009, 10:05:44 PM, you wrote:
> Bev,
> Good morning to you as well! I'd imagine that yes, the table-creation
> widget inside phpMyAdmin probably does execute the queries that way, as
> that seems to be its default mode. I'm not sure if you can change
> setti
> For instance, once the
> database reaches a certain size, you won't be able to back it up using
> phpMyAdmin, but will have to use the command line. That's sort of lame.
>
> At the bare minimum, if you're going to use phpMyAdmin to create
> tables, do it in raw SQL instead of using the widget.
Mark Armendariz wrote:
> li...@nopersonal.info wrote:
>> I've seen those odd little quotes on the few occasions that I've used
>> phpMySQL to create queries
> They're called backticks.
>
> http://dev.mysql.com/doc/refman/5.0/en/identifiers.html
Thanks, Mark
> Happy weekend.
You too.
Bev
li...@nopersonal.info wrote:
I've seen those odd little quotes on the few occasions that I've used
phpMySQL to create queries
They're called backticks.
http://dev.mysql.com/doc/refman/5.0/en/identifiers.html
Happy weekend.
Mark
___
New York PHP Us
Bev,
Good morning to you as well! I'd imagine that yes, the table-creation
widget inside phpMyAdmin probably does execute the queries that way, as
that seems to be its default mode. I'm not sure if you can change
settings to remove that behavior...
There are a lot of reasons to like phpMyAdm
At 1:18 AM -0400 8/30/09, li...@nopersonal.info wrote:
-snip-
In MySQL the exp_date field data type is DATE. I strongly suspect that
I'm handling my dates in the most verbose & confusing way possible,
True, you're not handling the date thing correctly, but you're close.
You need to understand
Good Morning Kristina,
Kristina D. H. Anderson wrote:
> phpMyAdmin often puts those funny sideways leaning apostrophes/quotes --
> ` -- around table names and field names when it writes its queries.
> You want to remove those before you create or change any table or field
> names, I think is w
Kristina D. H. Anderson wrote:
Also you can try to avoid your own confusion by giving longer, more
detailed names to fields. Some people hate this idea but to me a
little extra typing is worth the clarity.
Not only for yourself, but everyone else dealing with your database and code.
Also, I
Bev,
phpMyAdmin often puts those funny sideways leaning apostrophes/quotes --
` -- around table names and field names when it writes its queries.
You want to remove those before you create or change any table or field
names, I think is what he means in practical terms. That way you will
get
Hi Dan,
Daniel Convissor wrote:
> Your big mistake was delimiting the identifiers when creating the table.
>
> "Identifiers" are table names, field names, index names, etc. The
> "delimiter" for these is "`" in MySQL. When you use the delimiter around
> the identifiers, the database allows yo
>Your big mistake was delimiting the identifiers when creating the
table.
>
> "Identifiers" are table names, field names, index names, etc. The
> "delimiter" for these is "`" in MySQL. When you use the delimiter
around
> the identifiers, the database allows you to create nearly any name
you
Hi Bev:
> Creating a field/variable named desc and spending hours trying to figure
> out why MySQL was balking at my query with its typically enigmatic error
> messages.
Your big mistake was delimiting the identifiers when creating the table.
"Identifiers" are table names, field names, index nam
32 matches
Mail list logo
