This might be in the wrong group, but...
Here is an example of my data:
entry_id cat_id
1 20
2 25
3 30
4 25
5 35
6 25
2 30
2 35
3 35
As you can see, entry_id's 2 and 3 both belong to cat_id 30 and 35
I have captured the cat_id's 30 and 35 with my script, so I need all
entry_id's that belong to BOTH cat_id 30 and 35.
I tried "Select entry_id from myTable where cat_id = '30' and cat_id =
'35' but obviously that is incorrect.
Can someone help? Thanks...
Jun 2 '08
118  4515 
On Mon, 12 May 2008 12:59:45 -0400, Jerry Stuckle wrote:
>Pay attention to the posts. Peter's solution will work.
You can learn about grouping queries at this tutorial page:
http://www.w3schools.com/sql/sql_groupby.asp
Not necessarily. What happens if he has two entries with (2,30)? It
will fail.
Nothing in the description of the problem prohibits such an occurrence.
That can't occur because the first step in the solution is to strip duplicates.
--
Jamie Nelson
On Tue, 13 May 2008 12:02:59 -0400, Jerry Stuckle wrote:
>That was addressed in the response, but it looks like you missed it.
You make the mistake of assuming the data is not normalized. I think the
point of Peter's post was to ensure that the data was indeed normalized.
Which, if it is not normalized, will not work.
As I said - there was nothing in the original problem description to
prohibit it. And the correct answer doesn't require unique entries.
The data is always normalized because this was accomplished in the first
step. That should be obvious. You don't need redundant rows, hence they
can be removed.
--
Jamie Nelson
On Wed, 14 May 2008 03:32:01 -0500, Mitch Sherman wrote:
That's impossible if you have a unique index as the poster stated.
In a classic one-to-many (1:N) relationship, you shouldn't have any
duplicates. The recommendation to normalize your data is sound advice
which you seem to be disagreeing with.
The query you're suggesting will incorrectly overstate the number of
unique entries matched if there are duplicates. You should use "SELECT
DISTINCT" in that case.
Quite right.
The purpose of normalization is to remove redundancy.
This is what relational database gurus Hugh Darwin and C.J. Date say about
it:
"In other words, 'duplicate rows' are. absolutely, categorically, and
unequivocally outlawed. What we tell you three times is true."
Which is pretty explicit that duplicates are verboten!
--
Jamie Nelson
On Wed, 14 May 2008 10:59:46 -0400, Jerry Stuckle wrote:
But that was an additional condition the poster required - not the
original op. And that's what makes it incorrect.
False. Normalization can't hurt, thus doing it as the first step is
not incorrect, but actually a significant optimization that your solution
misses.
It may be very possible to have a perfectly normalized database but
duplicate columns here - there could be a third column which is also
part of the primary key, but not pertinent to this question, so was not
asked.
Adding columns doesn't matter, since normalization (step 1) can be done on
any table. All you have to do is specify an appropriate primary key.
In this case your query would fail. The one in comp.databases.mysql
would work correctly. Which is why I directed him there.
Not so, but you have to include the appropriate columns if you want to
work with a different relation.
Using the original problem, if you're too lazy to follow the instructions
and normalize the table, then simply add distinct:
SELECT entry_id FROM tbl WHERE cat_id IN (30, 35) GROUP BY
entry_id HAVING COUNT(DISTINCT entry_id, cat_id) = 2;
If you want to test more than 2 cat_id's, then you just add them to the IN
condition and increment the count. You can do this with an arbitrary
number of cat_id's. Your solution fails to handle this case.
Of course, you're better off implementing the entire solution and creating
a unique index on tbl (group_id, entry_id).
--
Jamie Nelson
On Thu, 15 May 2008 02:08:39 -0700, vkayute wrote:
Jerry's suggested query blows up when faced with duplicates, so you
can see how easy it is to fall into this trap.
This is because the join evaluates every possible combination and doesn't
exclude rows that were already matched. This could lead to a non-linear
expansion in the size of the result set which needless to say is a problem.
--
Jamie Nelson
Mitch Sherman wrote:
>
This is nonsense. Of course we have the definition. The poster
included it in his question. Furthermore, a normalized mapping of
entry_id -category_id has exactly 2 columns, not "2 or more". You
obviously don't understand this simple fact. This is a consequence of
the relational design. Learn some basics about normalization then get
back to us.
right, adding columns to this relation would not satisfy first normal
form, therefore there's no point in discussing this case.
Peter's solution still works in this case anyway, so your rant is
beside the point.
Yes, you would use count(DISTINCT entry_id, category_id) in the HAVING
clause. The original query is optimized for the binary relation posed in
the original problem, but if you want to go down this path it's easily done.
Your solution does not work at all however when
duplicates are allowed, which is the more serious problem that you
failed to address. It appears you''re hoping to sweep this under the
rug with a bunch of hand-waving blustering.
The funny thing is he thinks this is a "bug in MySQL" (*laugh*). That is
enough to dismiss him as a crackpot IMO.
Jerry Stuckle <js*******@attglobal.netwrote:
>
This table is 100% 1NF - but it has duplicates in the (userid, groupid)
entries:
userid groupid permission
1 1 read
1 1 write
1 1 delete
1 2 read
1 3 read
You are absolutely correct. I *suspect* the difference in opinion here
comes down to terminology; many people do not consider a database to be
"normalized" until it is 3NF, and the table above is not 3NF.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts wrote:
Jerry Stuckle <js*******@attglobal.netwrote:
>This table is 100% 1NF - but it has duplicates in the (userid, groupid)
entries:
userid groupid permission
1 1 read
1 1 write
1 1 delete
1 2 read
1 3 read
You are absolutely correct. I *suspect* the difference in opinion here
comes down to terminology; many people do not consider a database to be
"normalized" until it is 3NF, and the table above is not 3NF.
Actually, a primary key on (userid, groupid, permission) is possible -
and it would be 3NF.
3NF only requires all non-prime attributes to be directly dependent on
the prime attribute(s). It does not require non-prime attributes (i.e.
a many-to-many link table), nor does it require the prime attribute(s)
be a single column.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Jerry Stuckle wrote:
Mitch Sherman wrote:
No, my story has been consistent from the start. It's just some stoopid
morons here who can't understand that the table may be normalized - but
still have duplicates IN THESE TWO COLUMNS.
Who cares? If you are modeling a ternary relationship, then use COUNT
DISTINCT. This still has no bearing on the original problem however.
This is not a red herring. It is real life. If you're too stupid to
understand you don't have the entire table definition, then you need to
find another job.
It's a red herring because, even if we accept your flawed assumptions
that the poster meant something other than what he wrote, it doesn't
invalidate the original solution.
You're just wasting our time.
Tim Roberts wrote:
Jerry Stuckle <js*******@attglobal.netwrote:
This table is 100% 1NF - but it has duplicates in the (userid, groupid)
entries:
userid groupid permission
1 1 read
1 1 write
1 1 delete
1 2 read
1 3 read
You are absolutely correct. I *suspect* the difference in opinion here
comes down to terminology; many people do not consider a database to be
"normalized" until it is 3NF, and the table above is not 3NF.
Not quite correct, because Jerry's query still fails on this table
structure. This is easily demonstrated by this SQL example:
DROP TABLE IF EXISTS test;
CREATE TABLE test (
userid int not null,
groupid int not null,
permission char(6) not null,
primary key (groupid, userid, permission)
);
INSERT INTO test VALUES
(1, 1, 'read'),
(1, 1, 'write'),
(1, 1, 'delete'),
(1, 2, 'read'),
(1, 2, 'write'),
(1, 2, 'delete');
SELECT t1.groupid
FROM test AS t1
LEFT JOIN test AS t2
ON t1.userid = t2.userid
WHERE t1.groupid = 1 AND t2.groupid = 2;
His query returns:
9 rows in set (0.00 sec)
Jerry's query returned 9 rows, but there only 6 in the original table.
This is a serious inconsistency. His oft-repeated claim that his query
works with duplicates is clearly false. In another example that was
posted here, his query produced 200 million results in a table with
40,000 records. The more data you have, the more infeasible this
becomes.
Peter's approach works correctly however. The original query targeted
a binary relation posted by the OP. If you want to alter the problem
to have a ternary, quaternary, or higher dimension relation as in
Jerry's latest and greatest table design, then you simply use COUNT
DISTINCT like so:
SELECT userid
FROM test
WHERE groupid IN (1, 2)
GROUP BY userid
HAVING COUNT(DISTINCT userid, groupid) = 2;
However, what if you want to test for membership in not just 2 groups,
but 10, 100 or 1,000? That's easy to do with Peter's solution by
creating a simple function:
function group_intersection($group_ids)
{
$matches = array();
if (count($group_ids)) {
$set = join(', ', $group_ids);
$query = "SELECT userid FROM test WHERE
groupid IN ($set) GROUP BY userid HAVING
COUNT(DISTINCT userid, groupid) = " .
count($group_ids);
$db = getMdb2();
$matches = $db->extended->getCol($query);
}
return $matches;
}
$group_ids = range(1, 1000);
print_r(group_intersection($group_ids));
Let's see Jerry's solution do that... It can't, because it's
restricted to 2 groups only! That is a second serious deficiency in
his design, which doesn't pass muster in the real world where you
could have hundreds or thousands of groups defined.
--
Gary L. Simms
gary.l.simms at gmail.com
Jerry Stuckle <js*******@attglobal.netwrote:
ox*****@yahoo.com wrote:
>On May 15, 9:52 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>>Mitch Sherman wrote:
On Thu, 15 May 2008 11:55:29 -0400, Jerry Stuckle
<jstuck...@attglobal.netwrote:
>
I'm not arguing about proper database design. My only comment is it is
IMPOSSIBLE to determine if the database is normalized or not from the
given information.
>
That doesn't mean that the relation can't be normalized first. That
seems to be the critical point you're missing.
No, the critical point YOU'RE MISSING is that the table may be
normalized - AND STILL HAVE DUPLICATES IN THESE COLUMNS.
You're not speakign clearly here. First you said:
"It is IMPOSSIBLE to determine if the database is normalized or
not."
Then:
"The table may be normalized - AND STILL HAVE DUPLICATES IN THESE
COLUMNS."
In one case the table is not normalized, in the second it *is* normalized!
The poster was referring to the first case, which the solution deals
with properly by normalizing. The second case is not the same problem
at all.
This table is 100% 1NF - but it has duplicates in the (userid, groupid)
entries:
userid groupid permission
1 1 read
1 1 write
1 1 delete
1 2 read
1 3 read
No one is arguing that this new scenario is not 1NF.
Have you seen the CREATE TABLE definitions? If so, your crystal ball
must be working better than mine - because he sure as hell didn't post
it. And he could have had 200 additional columns in that table which he
didn't mention, because they were not germane to the question he posed.
He gave a concrete example of his data. There's no need to assume
anything outside that. He was clear he had a binary relation which
is always exactly 2 columns.
Guillaume <gg*****@nospam.gmail.com.invalidwrote:
ox*****@yahoo.com a ?crit :
>Here is the actual table structure:
>>Here is an example of my data:
Nice assert.
>There is no "userid", "groupid", or "permission". This is a linking
table that relates entry_id to cat_id.
You wish. Still, you assume. And you're wrong. I mean you're wrong to
assume, cause you may be right about the table structure. Note the word,
"may".
The poster gave a concrete example of his data which is equivalent to
an instance of his problem. Most people can recognize a many-to-many
relationship.
I'll just refer you to my previous comments here: http://groups.google.com/group/comp....d33733e0ee61aa
Jerry Stuckle <js*******@attglobal.netwrote:
>
How about this relationship:
groupid userid permission
1 1 read
1 1 write
1 1 delete
2 4 read
5 7 read
A perfectly normalized table
How do you know it's normalized? Maybe there are "extra columns"?
According to your argument a "CREATE TABLE" statement would
be necessary to actually determine that.
I think you've just proved the poster's point.
On Mon, 19 May 2008 11:35:32 +0200, Guillaume
<gg*****@NOSPAM.gmail.com.INVALIDwrote:
Any solution that involves a database would be wrong according to your
logic, so your premise is a bit contrived.
It is NOT incorrect to make reasonable inferences from a casually
posed question.
>Jerry claimed that this was a problem in the 2-column case:
On May 12, 12:59 pm, Jerry Stuckle wrote:
> >
Not necessarily. What happens if he has two entries with (2,30)?
It will fail.
>
No he claimed it was a problem FOR THESE 2 columns, amongst others.
His initial claim quoted above is what people were arguing with, not
the claim about the 3-column table. You either didn't read this or are
conveniently ignoring it. Frankly, he wasn't very clear. One minute he
had a table that was "not normalized", the next he's talking about a
3-column design that is "perfectly normalized."
>A B C
1 1 2
1 1 3
2 DB lines, 3 columns each, none is a duplicate. But considering process
on A & B only, there is a duplicate !
Oh no, this table has problems. What if you have a user in a group,
but that user has no permissions?
Which you cannot differentiate if you don't use column C in your process !
Not true at all, column C is never referenced at all! Where are you
getting this nonsense.
Here is the query revised to work with this design. You simply replace
(userid) with (DISTINCT groupid):
SELECT userid FROM test WHERE groupid IN (1, 2, 3, 4, 5)
GROUP BY userid HAVING COUNT(DISTINCT groupid) = 5;
Where on earth do you see column C here???
>Next Jerry proposed a new table that had a 3 column primary key.
Not the original problem at all.
Once again, you don't know. Unless you can tell me where the OP ever
said there *only* was 2 columns.
You seem to be deluded into thinking the question should be exactly
and formally specified, which is not possible unless you decide to
say, encode it in Peano arithmetic or predicate logic and have it
automatically verifiable by a computer. Again, use your reading
comprehension skills and make reasonable inferences such as assuming
SQL is available, even though he didn't explicitly say "I am using an
SQL database." It was strongly implied however by his reference to
"SELECT".
2 columns is a reasonable inference because a) his example problem
contained 2 columns, b) he said he intended to map entries to
categories, c) his question matches a well-known and common M:N design
pattern. Of all the possible relations he could be modelling, a
many-to-many is the best fit, so it's not incorrect to provide a
solution for this case.
This very assumption was stated up front in the solution (must create
a unique index), so I don't see what you're complaining about.
In comparison, the answer you prefer did NOT mention that duplicates
could be repeated in the result set (unless DISTINCT is added). The
other unstated assumption is that the poster would only want to search
2 groups. Why are you making that presumption, given that he may have
many more than 2 groups in his db?
>No one has said Jerry's new table is not normalized. They were simply
pointing out that duplicate rows cannot exist in a normalized table,
which is why the original solution works in the op's problem.
And Jerry pointed that the original problem MAY contain other columns,
thus it is still possible to have duplicates in the 2 columns he
described, considering an (or many) other one prevents duplicating records.
Again, you're confusing 2 differing claims. See above.
>The poster EXPLICITLY said "here is an example of my data" which is
absolutely clear. "Example" is synonymous with "instance."
Absolutely not clear. Thus completely wrong.
>Example of data is just what it is, an example.
Example means "an instance of the problem." It does not mean
"whatever."
Any solution that works correctly on the problem instance is correct.
Now you can debate which solution is qualitatively best, but that is
another matter. Formally, you are wrong.
It may not be accurate,
You're willing to negate everything the poster said. Not a reasonable
thing to do.
You seem to be rejecting induction completely as a method of solving
problems, which is fairly nutty.
>or not complete, it's not the data as they exist, it's just an example.
You seem to believe that a problem is either completely, formally, and
exactly specified, or that it's totally vague. This is a false
dichotomy.
An example does not need to be "complete." It merely needs to be a
concrete workable instance of an abstract idea.
And yes, you need to disambiguate between possible data types in his
table based on how he displayed them (no quotes) and how he named them
(id).
>What if the poster were parsing a file and said, "here is an example
of my data?" Would you assume that there were extra columns?
No absolutely not.
Why not ? O_o
What if he said he needed a regexp to match some text like '2008-05-20
10:05:00 AM'. Would you assume there could be trailing strings or
spaces embedded between the month and year?
Your "anything goes" premise doesn't make sense. You need to infer
the pattern that the person is trying to model. If he could already
specify it exactly as a regexp, he wouldn't have asked the question in
the first place.
>Well, depends on the file "structure", I would assume extra lines, I
would assume possible comments,
Why would you assume comments could exist? Just try adding comments to
a CSV file and you've corrupted it.
I would assume anything but "this file only contains the sample text and nothing else".
So you assume a C++ file could actually be parsed as a Java file.
Anything goes! Key word "assume" here. You agree that any solution
makes assumptions, hopefully usefule ones. Better to state your
assumptions than not to.
>According to you, we should not even presume that his database
supports SQL or that every entry in his actual list has the same
columns! It could be a variable list by your "logic."
My logic is "Jerry has a point, and there is no need to insult or
discriminate him". Which you don't, but you deny his point. As you wish,
but you need to proove that there is no extra columns. Which you can't.
Who insulted him? Jerry is the only one who engages in personal
attacks. You seem to be motivated by a desire to "defend his honour."
>Furthermore, he said entries belong to categories, which is
a binary, many-to-many relation (M:N) linking entry_id and
cat_id. If this were not a binary relation, then entries
would have to belong to categories plus something else.
Why not ? Why not the rights as stated by Jerry ?
An entry belong to a category and may have specific rights in it.
What if an entry belongs to a category, but that entry has no
"rights?" The only way to model this in a normalized fashion is a
2-column M:N table.
>Now if you believe the poster meant something other than what he
explicitly told us, then let's see your evidence.
I have no evidence to show you, it's not like you can say "this is what
the OP thought, if you think different proove it". You're the one that
should proove it since you give asserts (once again with "explicitely
told us"). My only point was that you can't know, that - though I admit
it's quite clear, and there should NOT be any other columns - it's still
not explicit.
Again, make reasonable inferences. It would be impossible for the
poster to explicitly state everythingpertaining to his problem. Did he
say he was using an SQL db? Maybe it's a flat file. Did he say he was
even using a computer and not sorting paper clips? Again, induction.
>You're actually missing the greater point which is
Which is that this is a PHP newsgroup, once again.
I don't care about all your "points", I don't care about Jerry's being
right or wrong, all I care about is some behavior that should not be.
And some argues as "Jerry is the only one thinking that way" which in no
way is an argue.
So you don't understand the whole point of the thread and don't care.
No wonder you're so confused.
>>Any chance this thread can stop, or continue in the sql newsgroup ?
*highly pissed*
Funny, posting multiple times to a thread that you wish would end.
Highly "logical."
This was my very first post on this thread...
And yet I won't stop as long as many people continue their ideas of "The
OP described the problem THAT way".
4 posts in a thread you wish would end! Keep it up, it's working!
I guess in some surreal universe posting additional messages actually
makes the thread shorter, rather than longer. Anything's possible in
Guillaume-o-verse!
Mitch
On Mon, 19 May 2008 19:58:41 -0400, Jerry Stuckle
<js*******@attglobal.netwrote:
>Mike Lahey wrote:
No, I NEVER SAID COUNT DISTINCT is a MySQL extension. Learn to read, idiot.
What you said was that an SQL query like this wasn't standard:
SELECT userid FROM test WHERE groupid IN (1, 2, 3, 4, 5)
GROUP BY userid HAVING COUNT(DISTINCT userid, groupid) = 5;
You went to great lengths to assert this "fact":
>Mike Lahey wrote:
>>Yes, you would use count(DISTINCT entry_id, category_id) in the
HAVING clause.
Jerry Stuckle wrote:
Which is not standard SQL and will not work in all databases. It is a
MySQL extension, and probably will work only in that database. The
correct solution is portable across all databases.
Jerry Stuckle wrote:
More show of ignorance. I never said COUNT DISTINCT wasn't defined in
ANSI SQL. I said the HAVING clause is NOT legal in ANSI SQL. But
you're too stoopid to understand why. And I'm NOT going to get into it
in a PHP newsgroup.
Totally wrong. This is completely valid SQL. It is not a "MySQL
extension."
You are trying real hard to spread some Jerrytastic FUD around.
If you still doubt, try it out here at the online SQL parser: http://www.wangz.net/gsqlparser/sqlpp/sqlformat.htm
>On May 15, 10:50 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
> CoreyJansen wrote:
Jerry's approach results in a "cartesian explosion."
Then you have a broken database server. You need to report
that as a bug to MySQL ASAP. A lot of people depend self-
join queries like this!
Again, put up or shut up. Let's your evidence that this ia a bug. Oh
that's right, you haven't got any!
Crackpot.
F'ing idiot.
Oh of course, anyone who tries to help you and correct your error is
an "idiot!"
Mitch
On Tue, 20 May 2008 17:07:13 +0200, Guillaume
<gg*****@NOSPAM.gmail.com.INVALIDwrote:
>Mitch Sherman wrote :
For this case. Which was Jerry's problem at first. Not (yet) talking
about normalized data and such, Jerry just said the proposed solution
was not correct, for an other case, if those "reasonable inferences"
were actually wrong.
Ah but this objection contains a hidden and incorrect assumption. The
original objections were:
1. "What happens if he has two entries with (2,30)"
2. "If it is not normalized, [it] will not work."
In 1, the entry tuple contains only 2 values. This is the 2 column
case. In 2, a non-normalized table in this context is one that
contains duplicated rows (rows, not just some columns). So this is
also the 2 column case.
Now it sounds like possibly a valid objection. But that is not quite
true, because there is no relational design (except a severely
pathological one) that requires redundant rows. The first step in
normalization is to remove dupliate rows. Since duplicates are never
needed to maintain logical consistency, they can be safely removed.
Doing that as the first step is thus not an error and is actually an
optimization.
To take another example: If I ask you to find the smallest element in
an array, would removing duplicate elements first be an error? No. The
db case is much stronger, since no table needs to house dupes in any
canonical design.
Playing devil's advocate, what if different threads insert (ent_id,
cat_id) rows constantly and are unable to handle a "key exists"
exception. I would argue that is not optimal and that code should be
fixed to properly handle the exception instead.
Later Jerry brough up a new table with 3 columns, and I agree with
Jerry that the solution would need a slight tweak to handle that case.
But this was mentioned explicitly in the original solution.
All we have to do is ask the OP which design he was using. Would you
care to wager cash on his actual table layout? I would be willing to
bet good money that (cat_id, ent_id) can be unique'd. (You could have
a one-column primary key called relation_id as in some designs, but
that would not prevent a unique index on the 2 entity columns.)
>I can quote him later on:
"And the query from comp.databases.mysql works correctly - in both
cases. Yours may work - but it isn't the best."
Problem is, the query in c.d.m did not actually work completely with
duplicates and did not state that up front. It needs to use SELECT
DISTINCT instead of SELECT to handle that case fully.
Further, that solution only works if you search a small number of
groups (eventually you hit a limit on joined tables), whereas the
original can handle many more. This is another case to consider, so
one solution cannot be said to work in "more cases" than the other.
>This very assumption was stated up front in the solution (must create
a unique index), so I don't see what you're complaining about.
I agree, but it's still not a solution, ain't it ?
"I have a problem" "Get that requirement, that solution and it's
solved"... yeah, but what if the OP cannot use that requirement, cause
his model is not just as expected, cause he wasn't clear enough ?
I'm not really willing to talk about database, I prefer dealing with a
general issue.
No db requires the presence of duplicates, so it's not inconsistent to
remove them.
>Let's say (and get back to PHP) someone is willing to do something he
can't cause of safe mode, without saying it (just saying here "I have
this error" which would be a safe mode issue).
One can reply "turn off safe mode, use that, and it's okay". Good reply,
but what if that user cannot turn safe mode, like someone just hosted by
his FAI ? Then it's not a solution, it just *might* have been one.
Yes it's reasonable to suggest turning off safe_mode, since that would
be the most direct solution and wouldn't require potentially
convoluted code rewrites. Overall it is the optimal path.
But, some people do say, "I can't turn off safe_mode," so in that
case, telling them to enable it would be an error.
But database tables don't need dupes (unless it's hopelessly
pathological). I don't think it's reasonable to assume a pathological
constraint in the absence of any indication one exists.
For instance, what if he can't use the letter 'F' in any SQL query, or
each SQL command needs to be exactly 60 chars long for some unknown
bizarre reason (maybe he's writing an SQL injection attack that has to
be constructed very carefully)? Why address a contrivance like that if
it wasn't stated. After all, people are trying to give advice based on
best practices.
>In fact, this thread should have turned into a "Please describe your
design exactly so you'll get the most accurate answer". Or, better, "ask
in a DB newsgroup". Which Jerry did, and he was flamed because of his
reply.
Anyway, this group's charter states that sql is not off-topic. As you
can see several replies in this there included PHP code.
>Though he was quite rude in his way, and flamed in return as well.
I guess nothing would have happened if he just started by saying this
"your solution may work, but it isn't the best".
(I skipped all parts related to pure SQL discussions, cause as I said:
- This is not the good NG,
- I'm not a MySQL expert and only use it in a casual way,
- I thus don't want to argue with things cause I may be wrong anyway.)
Mitch
Mitch Sherman <mi***********@hush.aiwrote:
>On Mon, 19 May 2008 19:58:41 -0400, Jerry Stuckle
<js*******@attglobal.netwrote:
>>Mike Lahey wrote:
No, I NEVER SAID COUNT DISTINCT is a MySQL extension. Learn to read, idiot.
What you said was that an SQL query like this wasn't standard:
SELECT userid FROM test WHERE groupid IN (1, 2, 3, 4, 5)
GROUP BY userid HAVING COUNT(DISTINCT userid, groupid) = 5;
You went to great lengths to assert this "fact":
>>Mike Lahey wrote:
Yes, you would use count(DISTINCT entry_id, category_id) in the
HAVING clause.
Jerry Stuckle wrote:
Which is not standard SQL and will not work in all databases. It is a
MySQL extension, and probably will work only in that database. The
correct solution is portable across all databases.
Jerry Stuckle wrote:
>More show of ignorance. I never said COUNT DISTINCT wasn't defined in
ANSI SQL. I said the HAVING clause is NOT legal in ANSI SQL. But
you're too stoopid to understand why. And I'm NOT going to get into it
in a PHP newsgroup.
Totally wrong. This is completely valid SQL. It is not a "MySQL
extension."
No, in this case, Jerry is right and you are wrong. In strict ANSI SQL,
any column reference in the HAVING clause must either be part of the result
set or one of the grouped columns. "groupid" is not present in the result
set, nor is it grouped.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
On Thu, 22 May 2008 04:39:17 GMT, Tim Roberts <ti**@probo.comwrote:
>No, in this case, Jerry is right and you are wrong. In strict ANSI SQL,
any column reference in the HAVING clause must either be part of the result
set or one of the grouped columns. "groupid" is not present in the result
set, nor is it grouped.
No, in SQL-92, aggregate functions like SUM and COUNT in the HAVING
clause may reference source columns, so this query is valid:
"Each <column referencecontained in a <subqueryin the <search
conditionthat references a column of T shall reference a
grouping column of T or shall be specified within a <set function
specification>."
SUM, AVG, COUNT, etc. are set function specifications.
So for example, SUM operates on all the individual rows within the
group:
DROP TABLE IF EXISTS test;
CREATE TABLE test (
userid INT NOT NULL,
groupid INT NOT NULL,
permission CHAR(6) NOT NULL,
PRIMARY KEY (groupid, userid, permission));
INSERT INTO test VALUES
(1, 1, 'read'), (1, 2, 'read'), (1, 3, 'read'),
(2, 1, 'read'), (2, 2, 'read'), (2, 3, 'read'),
(3, 1, 'read'), (3, 2, 'read'), (3, 3, 'read');
SELECT userid FROM test GROUP BY userid HAVING SUM(userid) = 9;
Returns:
userid
------
3
(1 row)
SELECT userid FROM test GROUP BY userid
HAVING SUM(userid) + SUM(groupid) = 12;
Rreturns:
userid
------
2
(1 row)
It works per standard in MySQL, PostgreSQL, Oracle.
Mitch
Tim Roberts wrote:
Mitch Sherman <mi***********@hush.aiwrote:
>On Mon, 19 May 2008 19:58:41 -0400, Jerry Stuckle
<js*******@attglobal.netwrote:
>>Mike Lahey wrote:
No, I NEVER SAID COUNT DISTINCT is a MySQL extension. Learn to read, idiot.
What you said was that an SQL query like this wasn't standard:
SELECT userid FROM test WHERE groupid IN (1, 2, 3, 4, 5)
GROUP BY userid HAVING COUNT(DISTINCT userid, groupid) = 5;
You went to great lengths to assert this "fact":
>>>Mike Lahey wrote:
Yes, you would use count(DISTINCT entry_id, category_id) in the
HAVING clause.
Jerry Stuckle wrote:
Which is not standard SQL and will not work in all databases. It is a
MySQL extension, and probably will work only in that database. The
correct solution is portable across all databases.
Jerry Stuckle wrote:
>>More show of ignorance. I never said COUNT DISTINCT wasn't defined in
ANSI SQL. I said the HAVING clause is NOT legal in ANSI SQL. But
you're too stoopid to understand why. And I'm NOT going to get into it
in a PHP newsgroup.
Totally wrong. This is completely valid SQL. It is not a "MySQL
extension."
No, in this case, Jerry is right and you are wrong. In strict ANSI SQL,
any column reference in the HAVING clause must either be part of the result
set or one of the grouped columns. "groupid" is not present in the result
set, nor is it grouped.
Tim,
Don't bother arguing with the idiot. He'll never admit that he's wrong.
He's even quoting a standard that has been out of date for over 10 years!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Jerry Stuckle a écrit :
Don't bother arguing with the idiot.
Jerry, shut up a bit with all those extraordinary argues... It's boring
and you don't need such replies.
Regards,
--
Guillaume
On May 22, 7:36 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
Tim Roberts wrote:
No, in this case, Jerry is right and you are wrong. In strict ANSI SQL,
any column reference in the HAVING clause must either be part of the result
set or one of the grouped columns. "groupid" is not present in the result
set, nor is it grouped.
Tim,
Don't bother arguing with the idiot. He'll never admit that he's wrong.
He's even quoting a standard that has been out of date for over 10 years!
This query is valid in every version since SQL-92.
The aggregate function aren't restricted to referencing
only grouping columns.
This part defines the relevant restriction on column
references in the HAVING clause:
Subclause 7.10, Syntax Rules, #3: "Each column
reference directly contained in the search condition
shall be one of the following: a) An unambiguous
reference to a column that is functionally dependent
on G. b) An outer reference."
[SQL/Foundation 2003/08]
This rule doesn't apply to columns in aggregate
functions because they aren't directly contained,
i.e.:
Subclause 6.3.3.1: "A1 directly contains B1 if A1
contains B1 without an intervening subquery, multiset
value constructor by query, table value constructor
by query, array value constructor by query, within
group specification, or set function specification
that is not an ordered set function."
[SQL/Framework 2003/08]
SQL-92 has a similar definition. Mitch Sherman was
incorrect in quoting the part about subqueries because
there is no subquery being used, but the query is still
valid for the reason he implied.
Aggregate functions like COUNT are set function
specifications and hence don't fall under rule #3
because the column references are not directly
contained in the HAVING condition. These aggregate
functions can reference any column in the argument
source, i.e.:
Subclause 6.7: "If QCR [query column reference] is
a within-group-varying column reference, then QCR
denotes the values of C in the rows of a given group
of the qualifying query of QCR used to construct the
argument source of a set function specification."
[SQL/Foundation 2003/08]
The argument source is a table or a group containing
N rows.
One example using this would be finding the customers
who transacted more than a certain amount in sales:
SELECT cust_id
FROM sale
GROUP by cust_id
HAVING SUM(amount) 500
There are some more examples of this pattern here: http://www.cs.jcu.edu.au/Subjects/cp...html#section48
On Tue, 13 May 2008 12:02:59 -0400, Jerry Stuckle
<js*******@attglobal.netwrote:
>>Not necessarily. What happens if he has two entries with (2,30)? It
will fail.
As I said - there was nothing in the original problem description to
prohibit it. And the correct answer doesn't require unique entries.
Sorry Jerry, I see that you're correct in this thred. I didn't mean to
suggest otherwise. The correct answer should work with duplicates or
without. Peter's answer is designed to work in a limited scenario.
Your answer (with DISTINCT as you said) is a better response.
Thanks for your help in understanding this SQL issue. I can see you
have a lot of experience in this area which helps to understand how to
properly model these problems.
Thanks again for your expert SQL recommendations in this thread and
many others.
Mitch
Mike Lahey wrote:
Jerry Stuckle wrote:
>You'll get good answers there because that's where the SQL experts
hang out. The answers posted here so far are incorrect.
Pay attention to the posts. Peter's solution will work.
You can learn about grouping queries at this tutorial page:
http://www.w3schools.com/sql/sql_groupby.asp
I was wrong too, and I apologize to Jerry Stuckle and the other posters
in this thread for being so obstinate and rude. I agree with Jerry's
analysis in this thread and he is correct as usual. Peter's solution
does not work in all cases, whereas Jerry's will. I retract my previous
posts in this thread which were rash and inappropriate.
Jerry was obviously correct all along. Thank you to Mr. Stuckle for his
brilliant analysis and patient explanations regarding this issue. I wont
waste any more of this group's time and will leave now.
Mike Lahey wrote:
>
>>
Not necessarily. What happens if he has two entries with (2,30)? It
will fail.
Nothing in the description of the problem prohibits such an occurrence.
That was addressed in the response, but it looks like you missed it.
You make the mistake of assuming the data is not normalized. I think the
point of Peter's post was to ensure that the data was indeed normalized.
I was wrong in this post, and I apologize to Jerry Stuckle and the other
posters in this thread for being so obstinate and rude. I agree with
Jerry's analysis in this thread and he is correct as usual. Peter's
solution does not work in all cases, whereas Jerry's will. I retract my
previous posts in this thread which were rash and inappropriate.
Jerry was obviously correct all along. Thank you to Mr. Stuckle for his
brilliant analysis and patient explanations regarding this issue. I wont
waste any more of this group's time and will leave now.
I was wrong in this post, and I apologize to Jerry Stuckle and the other
posters in this thread for being so obstinate and rude. I agree with
Jerry's analysis in this thread and he is correct as usual. Peter's
solution does not work in all cases, whereas Jerry's will. I retract my
previous posts in this thread which were rash and inappropriate.
Jerry was obviously correct all along. Thank you to Mr. Stuckle for his
brilliant analysis and patient explanations regarding this issue. I wont
waste any more of this group's time and will leave now.
Mike Lahey wrote:
Jerry Stuckle wrote:
>>
No argument.
But that was an additional condition the poster required - not the
original op. And that's what makes it incorrect.
Uniqueness is a consequence of the relationship the OP wanted to model.
Best practice is to create an index, which is the correct solution, as
has been pointed out several times.
You should properly normalize your DB instead of working around a broken
design as you're arguing for.
>It may be very possible to have a perfectly normalized database but
duplicate columns here - there could be a third column which is also
part of the primary key, but not pertinent to this question, so was
not asked.
For instance, you might have:
Game HomeTeam VisitingTeam
1 5 6
2 7 8
3 5 8
4 3 4
5 5 6
You want to know which teams played both team 6 and team 8. The Game
column is not pertinent to the question - but is critical to the game
design, because teams often play each other more than once.
This is not the same relationship. Teams can play each other more than
once, but a well-formed set cannot contain the same element twice.
Pay attention to the problem description which stated that entry_id's
belong to cat_id's. In your example however, HomeTeam and VisitingTeam
have parity instead. Re-read the original question:
Chuck Cheeze wrote:
Here is an example of my data:
>
entry_id cat_id
1 20
2 25
3 30
4 25
5 35
6 25
2 30
2 35
3 35
>
As you can see, entry_id's 2 and 3 both belong to cat_id 30 and 35
>
I have captured the cat_id's 30 and 35 with my script, so I need all
entry_id's that belong to BOTH cat_id 30 and 35.
The OP wanted to indicate membership in a group. A membership relation
does not contain duplicates. Your query wont work in your example
because it doesn't report which visitors played those teams, since each
team can either be at home or away.
You've changed the problem, hence you need a new query.
I was wrong in this post, and I apologize to Jerry Stuckle and the other
posters in this thread for being so obstinate and rude. I agree with
Jerry's analysis in this thread and he is correct as usual. Peter's
solution does not work in all cases, whereas Jerry's will. I retract my
previous posts in this thread which were rash and inappropriate.
Jerry was obviously correct all along. Thank you to Mr. Stuckle for his
brilliant analysis and patient explanations regarding this issue. I wont
waste any more of this group's time and will leave now.
Mike Lahey wrote:
Mitch Sherman wrote:
>
This is nonsense. Of course we have the definition. The poster
included it in his question. Furthermore, a normalized mapping of
entry_id -category_id has exactly 2 columns, not "2 or more". You
obviously don't understand this simple fact. This is a consequence of
the relational design. Learn some basics about normalization then get
back to us.
right, adding columns to this relation would not satisfy first normal
form, therefore there's no point in discussing this case.
[...]
Mike Lahey wrote:
Jerry Stuckle wrote:
>And why is that nonsense? He told us about TWO COLUMNS in his table.
He never said these were THE ONLY TWO COLUMN. He might have had 200
more, for all we know. But being immaterial to the question at hand,
he would not have posted the superfluous information - which is the
correct thing to do.
False. His problem described a binary relation. Your mysterious
"200-column table", while it may exist, isn't relevant to the poster's
question.
[...]
I was wrong in this post, and I apologize to Jerry Stuckle and the other
posters in this thread for being so obstinate and rude. I agree with
Jerry's analysis in this thread and he is correct as usual. Peter's
solution does not work in all cases, whereas Jerry's will. I retract my
previous posts in this thread which were rash and inappropriate.
Jerry was obviously correct all along. Thank you to Mr. Stuckle for his
brilliant analysis and patient explanations regarding this issue. I wont
waste any more of this group's time and will leave now.
Mike Lahey wrote:
Jerry Stuckle wrote:
>Mitch Sherman wrote:
>No, my story has been consistent from the start. It's just some
stoopid morons here who can't understand that the table may be
normalized - but still have duplicates IN THESE TWO COLUMNS.
Who cares? If you are modeling a ternary relationship, then use COUNT
DISTINCT. This still has no bearing on the original problem however.
[...]
I was wrong in this post, and I apologize to Jerry Stuckle and the other
posters in this thread for being so obstinate and rude. I agree with
Jerry's analysis in this thread and he is correct as usual. Peter's
solution does not work in all cases, whereas Jerry's will. I retract my
previous posts in this thread which were rash and inappropriate.
Jerry was obviously correct all along. Thank you to Mr. Stuckle for his
brilliant analysis and patient explanations regarding this issue. I wont
waste any more of this group's time and will leave now.
Mike Lahey wrote:
Put up
[...]
I was wrong in this post, and I apologize to Jerry Stuckle and the other
posters in this thread for being so obstinate and rude. I agree with
Jerry's analysis in this thread and he is correct as usual. Peter's
solution does not work in all cases, whereas Jerry's will. I retract my
previous posts in this thread which were rash and inappropriate.
Jerry was obviously correct all along. Thank you to Mr. Stuckle for his
brilliant analysis and patient explanations regarding this issue. I wont
waste any more of this group's time and will leave now.
Mike Lahey wrote:
again, put up
[...]
I was wrong in this post, and I apologize to Jerry Stuckle and the other
posters in this thread for being so obstinate and rude. I agree with
Jerry's analysis in this thread and he is correct as usual. Peter's
solution does not work in all cases, whereas Jerry's will. I retract my
previous posts in this thread which were rash and inappropriate.
Jerry was obviously correct all along. Thank you to Mr. Stuckle for his
brilliant analysis and patient explanations regarding this issue. I wont
waste any more of this group's time and will leave now.
Jerry Stuckle wrote:
Chuck Cheeze wrote:
This isn't a PHP question - it's a database question. You need a group
for your database (i.e. if it's MySQL, comp.databases.mysql).
You'll get good answers there because that's where the SQL experts hang
out. The answers posted here so far are incorrect.
You were right Jerry, I'm sorry for starting a pointless argument with you.
Chuck Cheeze wrote:
This might be in the wrong group, but...
Here is an example of my data:
entry_id cat_id
1 20
2 25
3 30
4 25
5 35
6 25
2 30
2 35
3 35
As you can see, entry_id's 2 and 3 both belong to cat_id 30 and 35
I have captured the cat_id's 30 and 35 with my script, so I need all
entry_id's that belong to BOTH cat_id 30 and 35.
I tried "Select entry_id from myTable where cat_id = '30' and cat_id =
'35' but obviously that is incorrect.
Can someone help? Thanks...
I was wrong and I apologize to Jerry Stuckle and the other posters in
this thread for being so obstinate and rude. I agree with Jerry's
analysis in this thread and he is correct as usual. Peter's solution
does not work in all cases, whereas Jerry's will. I retract my previous
posts in this thread which were rash and inappropriate.
Jerry was obviously correct all along. Thank you to Mr. Stuckle for his
brilliant analysis and patient explanations regarding this issue. I wont
waste any more of this group's time and will leave now.
On Sun, 11 May 2008 09:57:33 -0400, Jerry Stuckle
<js*******@attglobal.netwrote:
>
This isn't a PHP question - it's a database question. You need a group
for your database (i.e. if it's MySQL, comp.databases.mysql).
You'll get good answers there because that's where the SQL experts hang
out. The answers posted here so far are incorrect.
Jerry is correct. The answer posted in comp.databases.mysql (with
DISTINC) correct. The original one posted by petersprc isn't. Thanks,
Jerry.
Mitch
On Wed, 14 May 2008 03:32:01 -0500, Mitch Sherman
<mi***********@hush.aiwrote:
>On Tue, 13 May 2008 12:02:59 -0400, Jerry Stuckle
<js*******@attglobal.netwrote:
>>Mike Lahey wrote:
>>That was addressed in the response, but it looks like you missed it.
You make the mistake of assuming the data is not normalized. I think the
point of Peter's post was to ensure that the data was indeed normalized.
Which, if it is not normalized, will not work.
As I said - there was nothing in the original problem description to
prohibit it. And the correct answer doesn't require unique entries.
That's impossible if you have a unique index as the poster stated.
In a classic one-to-many (1:N) relationship, you shouldn't have any
duplicates. The recommendation to normalize your data is sound advice
which you seem to be disagreeing with.
The query you're suggesting will incorrectly overstate the number of
unique entries matched if there are duplicates. You should use "SELECT
DISTINCT" in that case.
Mitch
Well this post of mine was a bit incorrect. The original problem might
not permit a unique index on these 2 columns, so it wouldn't be
correct to require it.
Mitch
On Thu, 15 May 2008 21:33:55 -0500, Mitch Sherman
<mi***********@hush.aiwrote:
>This is a pointless hypothetical. If you have N columns, you can still
maintain uniqueness across those columns. That doesn't require
duplicate rows any more than the original problem which had only 2
columns.
Mitch
Imissed Jerry's point I think. There might be dups in 2 of N columns,
and not all N, so the table would still be normalized, but a unique
index on those 2 columns wouldn't be possible.
Mitch
On Tue, 20 May 2008 09:04:44 -0500, Mitch Sherman
<mi***********@hush.aiwrote:
>On Mon, 19 May 2008 11:35:32 +0200, Guillaume
<gg*****@NOSPAM.gmail.com.INVALIDwrote:
Any solution that involves a database would be wrong according to your
logic, so your premise is a bit contrived.
It is NOT incorrect to make reasonable inferences from a casually
posed question.
>>Jerry claimed that this was a problem in the 2-column case:
On May 12, 12:59 pm, Jerry Stuckle wrote:
>
Not necessarily. What happens if he has two entries with (2,30)?
It will fail.
>
No he claimed it was a problem FOR THESE 2 columns, amongst others.
His initial claim quoted above is what people were arguing with, not
the claim about the 3-column table. You either didn't read this or are
conveniently ignoring it. Frankly, he wasn't very clear. One minute he
had a table that was "not normalized", the next he's talking about a
3-column design that is "perfectly normalized."
>>A B C
1 1 2
1 1 3
2 DB lines, 3 columns each, none is a duplicate. But considering process
on A & B only, there is a duplicate !
Oh no, this table has problems. What if you have a user in a group,
but that user has no permissions?
>Which you cannot differentiate if you don't use column C in your process !
Not true at all, column C is never referenced at all! Where are you
getting this nonsense.
Here is the query revised to work with this design. You simply replace
(userid) with (DISTINCT groupid):
SELECT userid FROM test WHERE groupid IN (1, 2, 3, 4, 5)
GROUP BY userid HAVING COUNT(DISTINCT groupid) = 5;
Where on earth do you see column C here???
>>Next Jerry proposed a new table that had a 3 column primary key.
Not the original problem at all.
Once again, you don't know. Unless you can tell me where the OP ever
said there *only* was 2 columns.
You seem to be deluded into thinking the question should be exactly
and formally specified, which is not possible unless you decide to
say, encode it in Peano arithmetic or predicate logic and have it
automatically verifiable by a computer. Again, use your reading
comprehension skills and make reasonable inferences such as assuming
SQL is available, even though he didn't explicitly say "I am using an
SQL database." It was strongly implied however by his reference to
"SELECT".
2 columns is a reasonable inference because a) his example problem
contained 2 columns, b) he said he intended to map entries to
categories, c) his question matches a well-known and common M:N design
pattern. Of all the possible relations he could be modelling, a
many-to-many is the best fit, so it's not incorrect to provide a
solution for this case.
This very assumption was stated up front in the solution (must create
a unique index), so I don't see what you're complaining about.
In comparison, the answer you prefer did NOT mention that duplicates
could be repeated in the result set (unless DISTINCT is added). The
other unstated assumption is that the poster would only want to search
2 groups. Why are you making that presumption, given that he may have
many more than 2 groups in his db?
>>No one has said Jerry's new table is not normalized. They were simply
pointing out that duplicate rows cannot exist in a normalized table,
which is why the original solution works in the op's problem.
And Jerry pointed that the original problem MAY contain other columns,
thus it is still possible to have duplicates in the 2 columns he
described, considering an (or many) other one prevents duplicating records.
Again, you're confusing 2 differing claims. See above.
>>The poster EXPLICITLY said "here is an example of my data" which is
absolutely clear. "Example" is synonymous with "instance."
Absolutely not clear. Thus completely wrong.
>>Example of data is just what it is, an example.
Example means "an instance of the problem." It does not mean
"whatever."
Any solution that works correctly on the problem instance is correct.
Now you can debate which solution is qualitatively best, but that is
another matter. Formally, you are wrong.
>It may not be accurate,
You're willing to negate everything the poster said. Not a reasonable
thing to do.
You seem to be rejecting induction completely as a method of solving
problems, which is fairly nutty.
>>or not complete, it's not the data as they exist, it's just an example.
You seem to believe that a problem is either completely, formally, and
exactly specified, or that it's totally vague. This is a false
dichotomy.
An example does not need to be "complete." It merely needs to be a
concrete workable instance of an abstract idea.
And yes, you need to disambiguate between possible data types in his
table based on how he displayed them (no quotes) and how he named them
(id).
>>What if the poster were parsing a file and said, "here is an example
of my data?" Would you assume that there were extra columns?
No absolutely not.
Why not ? O_o
What if he said he needed a regexp to match some text like '2008-05-20
10:05:00 AM'. Would you assume there could be trailing strings or
spaces embedded between the month and year?
Your "anything goes" premise doesn't make sense. You need to infer
the pattern that the person is trying to model. If he could already
specify it exactly as a regexp, he wouldn't have asked the question in
the first place.
>>Well, depends on the file "structure", I would assume extra lines, I
would assume possible comments,
Why would you assume comments could exist? Just try adding comments to
a CSV file and you've corrupted it.
>I would assume anything but "this file only contains the sample text and nothing else".
So you assume a C++ file could actually be parsed as a Java file.
Anything goes! Key word "assume" here. You agree that any solution
makes assumptions, hopefully usefule ones. Better to state your
assumptions than not to.
>>According to you, we should not even presume that his database
supports SQL or that every entry in his actual list has the same
columns! It could be a variable list by your "logic."
My logic is "Jerry has a point, and there is no need to insult or
discriminate him". Which you don't, but you deny his point. As you wish,
but you need to proove that there is no extra columns. Which you can't.
Who insulted him? Jerry is the only one who engages in personal
attacks. You seem to be motivated by a desire to "defend his honour."
>>Furthermore, he said entries belong to categories, which is
a binary, many-to-many relation (M:N) linking entry_id and
cat_id. If this were not a binary relation, then entries
would have to belong to categories plus something else.
Why not ? Why not the rights as stated by Jerry ?
An entry belong to a category and may have specific rights in it.
What if an entry belongs to a category, but that entry has no
"rights?" The only way to model this in a normalized fashion is a
2-column M:N table.
>>Now if you believe the poster meant something other than what he
explicitly told us, then let's see your evidence.
I have no evidence to show you, it's not like you can say "this is what
the OP thought, if you think different proove it". You're the one that
should proove it since you give asserts (once again with "explicitely
told us"). My only point was that you can't know, that - though I admit
it's quite clear, and there should NOT be any other columns - it's still
not explicit.
Again, make reasonable inferences. It would be impossible for the
poster to explicitly state everythingpertaining to his problem. Did he
say he was using an SQL db? Maybe it's a flat file. Did he say he was
even using a computer and not sorting paper clips? Again, induction.
>>You're actually missing the greater point which is
Which is that this is a PHP newsgroup, once again.
I don't care about all your "points", I don't care about Jerry's being
right or wrong, all I care about is some behavior that should not be.
And some argues as "Jerry is the only one thinking that way" which in no
way is an argue.
So you don't understand the whole point of the thread and don't care.
No wonder you're so confused.
>>>Any chance this thread can stop, or continue in the sql newsgroup ?
*highly pissed*
Funny, posting multiple times to a thread that you wish would end.
Highly "logical."
This was my very first post on this thread...
And yet I won't stop as long as many people continue their ideas of "The
OP described the problem THAT way".
4 posts in a thread you wish would end! Keep it up, it's working!
I guess in some surreal universe posting additional messages actually
makes the thread shorter, rather than longer. Anything's possible in
Guillaume-o-verse!
Mitch
Disregard this post I made Guillaume. I see your point now. Certainly
the poster's question was amiguous and could've matched many
reasonable scnarios. The best solution will work in all those
scenarios, so you're right that Jerry's critique is correct.
Mitch
I see what Jerry meant now, so I was wrong.
On Tue, 20 May 2008 11:48:50 -0500, Mitch Sherman
<mi***********@hush.aiwrote:
>On Tue, 20 May 2008 17:07:13 +0200, Guillaume
<gg*****@NOSPAM.gmail.com.INVALIDwrote:
>>Mitch Sherman wrote :
For this case. Which was Jerry's problem at first. Not (yet) talking
about normalized data and such, Jerry just said the proposed solution
was not correct, for an other case, if those "reasonable inferences"
were actually wrong.
Ah but this objection contains a hidden and incorrect assumption. The
original objections were:
1. "What happens if he has two entries with (2,30)"
2. "If it is not normalized, [it] will not work."
In 1, the entry tuple contains only 2 values. This is the 2 column
case. In 2, a non-normalized table in this context is one that
contains duplicated rows (rows, not just some columns). So this is
also the 2 column case.
Now it sounds like possibly a valid objection. But that is not quite
true, because there is no relational design (except a severely
pathological one) that requires redundant rows. The first step in
normalization is to remove dupliate rows. Since duplicates are never
needed to maintain logical consistency, they can be safely removed.
Doing that as the first step is thus not an error and is actually an
optimization.
To take another example: If I ask you to find the smallest element in
an array, would removing duplicate elements first be an error? No. The
db case is much stronger, since no table needs to house dupes in any
canonical design.
Playing devil's advocate, what if different threads insert (ent_id,
cat_id) rows constantly and are unable to handle a "key exists"
exception. I would argue that is not optimal and that code should be
fixed to properly handle the exception instead.
Later Jerry brough up a new table with 3 columns, and I agree with
Jerry that the solution would need a slight tweak to handle that case.
But this was mentioned explicitly in the original solution.
All we have to do is ask the OP which design he was using. Would you
care to wager cash on his actual table layout? I would be willing to
bet good money that (cat_id, ent_id) can be unique'd. (You could have
a one-column primary key called relation_id as in some designs, but
that would not prevent a unique index on the 2 entity columns.)
>>I can quote him later on:
"And the query from comp.databases.mysql works correctly - in both
cases. Yours may work - but it isn't the best."
Problem is, the query in c.d.m did not actually work completely with
duplicates and did not state that up front. It needs to use SELECT
DISTINCT instead of SELECT to handle that case fully.
Further, that solution only works if you search a small number of
groups (eventually you hit a limit on joined tables), whereas the
original can handle many more. This is another case to consider, so
one solution cannot be said to work in "more cases" than the other.
>>This very assumption was stated up front in the solution (must create
a unique index), so I don't see what you're complaining about.
I agree, but it's still not a solution, ain't it ?
"I have a problem" "Get that requirement, that solution and it's
solved"... yeah, but what if the OP cannot use that requirement, cause
his model is not just as expected, cause he wasn't clear enough ?
I'm not really willing to talk about database, I prefer dealing with a
general issue.
No db requires the presence of duplicates, so it's not inconsistent to
remove them.
>>Let's say (and get back to PHP) someone is willing to do something he
can't cause of safe mode, without saying it (just saying here "I have
this error" which would be a safe mode issue).
One can reply "turn off safe mode, use that, and it's okay". Good reply,
but what if that user cannot turn safe mode, like someone just hosted by
his FAI ? Then it's not a solution, it just *might* have been one.
Yes it's reasonable to suggest turning off safe_mode, since that would
be the most direct solution and wouldn't require potentially
convoluted code rewrites. Overall it is the optimal path.
But, some people do say, "I can't turn off safe_mode," so in that
case, telling them to enable it would be an error.
But database tables don't need dupes (unless it's hopelessly
pathological). I don't think it's reasonable to assume a pathological
constraint in the absence of any indication one exists.
For instance, what if he can't use the letter 'F' in any SQL query, or
each SQL command needs to be exactly 60 chars long for some unknown
bizarre reason (maybe he's writing an SQL injection attack that has to
be constructed very carefully)? Why address a contrivance like that if
it wasn't stated. After all, people are trying to give advice based on
best practices.
>>In fact, this thread should have turned into a "Please describe your
design exactly so you'll get the most accurate answer". Or, better, "ask
in a DB newsgroup". Which Jerry did, and he was flamed because of his
reply.
Anyway, this group's charter states that sql is not off-topic. As you
can see several replies in this there included PHP code.
>>Though he was quite rude in his way, and flamed in return as well.
I guess nothing would have happened if he just started by saying this
"your solution may work, but it isn't the best".
(I skipped all parts related to pure SQL discussions, cause as I said:
- This is not the good NG,
- I'm not a MySQL expert and only use it in a casual way,
- I thus don't want to argue with things cause I may be wrong anyway.)
Mitch
On Thu, 15 May 2008 21:49:03 -0500, Mitch Sherman
<mi***********@hush.aiwrote:
>On Thu, 15 May 2008 11:50:57 -0400, Jerry Stuckle
<js*******@attglobal.netwrote:
>>Corey Jansen wrote:
>>>
Jerry's approach results in a "cartesian explosion."
Then you have a broken database server. You need to report that as a
bug to MySQL ASAP. A lot of people depend self-join queries like this!
Not at all, this is a bug in your query. It produced the same result
here. MySQL did exactly what you told it to do. You seem desperate to
avoid acknowledging this, resorting even to making up fictitious MySQL
bug reports.
The problem is you are self-joining using a condition that isn't
unique and lacks a primary key reference. Sometimes this is what you
want, but that is not the case in the original problem.
Let me spell it out for you. Let's say you have rows A through F that
contain the following values:
A: (2, 30)
B: (2, 35)
C: (2, 30)
D: (2, 35)
E: (2, 30)
F: (2, 35)
There are only 6 rows in the table. Your query, however, will produce
more than 6 matches. This is because rows A, C, and E can each be
paired a total of 3 times. The result of the inner join is:
(A, B), (A, D), (A, F)
(C, B), (C, D), (C, F)
(E, B), (E, D), (E, F)
Now, here's how it looks in SQL:
-- Create the table with 6 rows --
DROP TABLE IF EXISTS test;
CREATE TABLE test (entry_id int, cat_id int);
INSERT INTO test (entry_id, cat_id) values
(2, 30), (2, 35), (2, 30), (2, 35), (2, 30),
(2, 35);
-- Run the query --
SELECT a.entry_id FROM test a INNER JOIN test b
ON a.entry_id = b.entry_id WHERE a.entry_id =
b.entry_id AND a.cat_id = 30 AND b.cat_id = 35;
The result of your query is:
9 rows in set (0.00 sec)
This gets worse as your table gets bigger. You end up with the
"cartesian explosion" in the test case that you are denying exists.
>>
This works fine (sorry about the line wraps):
<?php
$link = mysql_connect('localhost', 'root', 'vps11131') or die("Can't
connect: " . mysql_error());
$db = mysql_select_db('test');
// Clear table if it existed
mysql_query('DROP TABLE IF EXISTS test');
mysql_query('CREATE TABLE test (groupid INT NOT NULL, ' .
'userid INT NOT NULL, PRIMARY KEY(groupid, userid))');
Your script doesn't test the same scenario at all. The table you
created is guaranteed not to have any duplicates because you defined a
PRIMARY KEY. This is exactly what you've been arguing against doing
all this time, so you've basically demonstrated why uniqueness is a
good thing.
Mitch
Well, this is a pathological example that wouldn't really happen.
Jerry's query is correct, and any dups in the result set can be
removed by using select distinct...
Mitch
I misunderstood that he meant 2 of N columns aren't unique, as opposed
to all columns are duplicated.
Mitch
On Thu, 15 May 2008 21:55:53 -0500, Mitch Sherman
<mi***********@hush.aiwrote:
>On Thu, 15 May 2008 12:01:02 -0400, Jerry Stuckle
<js*******@attglobal.netwrote:
>>vk*****@gmail.com wrote:
>>On May 14, 7:21 pm, Mike Lahey <mikey6...@yahoo.comwrote:
Jerry Stuckle wrote:
No argument.
But that was an additional condition the poster required - not the
original op. And that's what makes it incorrect.
Uniqueness is a consequence of the relationship the OP wanted to model.
Best practice is to create an index, which is the correct solution, as
has been pointed out several times.
You should properly normalize your DB instead of working around a broken
design as you're arguing for.
Amen. Any proposed solution that skips this step is incomplete. One
shouldn't rely on a broken data model and expect to get good results.
No arguments. But based on the information given, we cannot say the
database was not normalized.
Normalizing it first can do no harm and is certainly an improvement. A
relational table doesn't need redundant rows.
>>>The OP wanted to indicate membership in a group. A membership relation
does not contain duplicates.
Yes, by definition, a membership set has no dups. To take another
example, it wouldn't be proper for a student to belong to the same
class twice. (He could repeat the course, but that wouldn't be the
same class would it.)
It depends. For instance, you could have an additional column -
privileges. Things like "read", "post", "upload" to determine the
rights the user has.
Doesn't matter. Each row is still unique. Why would you specify the
same "rights" twice when once is enough? There is no relational design
that you can postulate that requires redundancy. This can always be
eliminated.
>>Using a flawed db design creates all sorts of inconsistencies which
are better to avoid when developing robust systems.
Jerry's suggested query blows up when faced with duplicates, so you
can see how easy it is to fall into this trap.
My query does not blow up with there are duplicates. It works perfectly
well. But Peter's fails in that case.
And people wonder why I refer MySQL questions to comp.databases.mysql -
where the real experts hang out.
There have been several posts pointing out your error, but you seem
desperate to cling to the idea that this is a "bug in MySQL" rather
than a flawed design. You made the same mistake Peter warned you
against. His approach is superior to yours because it both a)
normalizes (by removing dups) and b) optimizes by creating an index.
Your solution does neither and does not even properly handle duplicate
rows.
Mitch
On Tue, 20 May 2008 09:20:39 -0500, Mitch Sherman
<mi***********@hush.aiwrote:
>On Mon, 19 May 2008 19:58:41 -0400, Jerry Stuckle
<js*******@attglobal.netwrote:
>>Mike Lahey wrote:
No, I NEVER SAID COUNT DISTINCT is a MySQL extension. Learn to read, idiot.
What you said was that an SQL query like this wasn't standard:
SELECT userid FROM test WHERE groupid IN (1, 2, 3, 4, 5)
GROUP BY userid HAVING COUNT(DISTINCT userid, groupid) = 5;
You went to great lengths to assert this "fact":
>>Mike Lahey wrote:
Yes, you would use count(DISTINCT entry_id, category_id) in the
HAVING clause.
Jerry Stuckle wrote:
Which is not standard SQL and will not work in all databases. It is a
MySQL extension, and probably will work only in that database. The
correct solution is portable across all databases.
Jerry Stuckle wrote:
>More show of ignorance. I never said COUNT DISTINCT wasn't defined in
ANSI SQL. I said the HAVING clause is NOT legal in ANSI SQL. But
you're too stoopid to understand why. And I'm NOT going to get into it
in a PHP newsgroup.
Totally wrong. This is completely valid SQL. It is not a "MySQL
extension."
You are trying real hard to spread some Jerrytastic FUD around.
If you still doubt, try it out here at the online SQL parser:
http://www.wangz.net/gsqlparser/sqlpp/sqlformat.htm
>>On May 15, 10:50 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
CoreyJansen wrote:
Jerry's approach results in a "cartesian explosion."
>
Then you have a broken database server. You need to report
that as a bug to MySQL ASAP. A lot of people depend self-
join queries like this!
Again, put up or shut up. Let's your evidence that this ia a bug. Oh
that's right, you haven't got any!
Crackpot.
F'ing idiot.
Oh of course, anyone who tries to help you and correct your error is
an "idiot!"
Mitch
I think I misrepresented what Jerry Stuckle posted here. Disregard my
post.
Mitch
Disregard all my posts from prior days in this thread please. It looks
like I misunderstood what Jerry, Guillaume, Tim Roberts, Captain
Paralytic, and others were saying and made a fool of myself!
I apologize for this to all.
Mitch
<mi***********@hush.aiwrote:
>On Mon, 19 May 2008 19:58:41 -0400, Jerry Stuckle
<js*******@attglobal.netwrote:
>>Mike Lahey wrote:
No, I NEVER SAID COUNT DISTINCT is a MySQL extension. Learn to read, idiot.
What you said was that an SQL query like this wasn't standard:
SELECT userid FROM test WHERE groupid IN (1, 2, 3, 4, 5)
GROUP BY userid HAVING COUNT(DISTINCT userid, groupid) = 5;
You went to great lengths to assert this "fact":
>>Mike Lahey wrote:
Yes, you would use count(DISTINCT entry_id, category_id) in the
HAVING clause.
Jerry Stuckle wrote:
Which is not standard SQL and will not work in all databases. It is a
MySQL extension, and probably will work only in that database. The
correct solution is portable across all databases.
Jerry Stuckle wrote:
>More show of ignorance. I never said COUNT DISTINCT wasn't defined in
ANSI SQL. I said the HAVING clause is NOT legal in ANSI SQL. But
you're too stoopid to understand why. And I'm NOT going to get into it
in a PHP newsgroup.
Totally wrong. This is completely valid SQL. It is not a "MySQL
extension."
You are trying real hard to spread some Jerrytastic FUD around.
If you still doubt, try it out here at the online SQL parser:
http://www.wangz.net/gsqlparser/sqlpp/sqlformat.htm
>>On May 15, 10:50 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
CoreyJansen wrote:
Jerry's approach results in a "cartesian explosion."
>
Then you have a broken database server. You need to report
that as a bug to MySQL ASAP. A lot of people depend self-
join queries like this!
Again, put up or shut up. Let's your evidence that this ia a bug. Oh
that's right, you haven't got any!
Crackpot.
F'ing idiot.
Oh of course, anyone who tries to help you and correct your error is
an "idiot!"
Mitch
On Tue, 20 May 2008 09:20:39 -0500, Mitch Sherman
<mi***********@hush.aiwrote:
>On Mon, 19 May 2008 19:58:41 -0400, Jerry Stuckle
<js*******@attglobal.netwrote:
>>Mike Lahey wrote:
No, I NEVER SAID COUNT DISTINCT is a MySQL extension. Learn to read, idiot.
What you said was that an SQL query like this wasn't standard:
SELECT userid FROM test WHERE groupid IN (1, 2, 3, 4, 5)
GROUP BY userid HAVING COUNT(DISTINCT userid, groupid) = 5;
You went to great lengths to assert this "fact":
>>Mike Lahey wrote:
Yes, you would use count(DISTINCT entry_id, category_id) in the
HAVING clause.
Jerry Stuckle wrote:
Which is not standard SQL and will not work in all databases. It is a
MySQL extension, and probably will work only in that database. The
correct solution is portable across all databases.
Jerry Stuckle wrote:
>More show of ignorance. I never said COUNT DISTINCT wasn't defined in
ANSI SQL. I said the HAVING clause is NOT legal in ANSI SQL. But
you're too stoopid to understand why. And I'm NOT going to get into it
in a PHP newsgroup.
Totally wrong. This is completely valid SQL. It is not a "MySQL
extension."
You are trying real hard to spread some Jerrytastic FUD around.
If you still doubt, try it out here at the online SQL parser:
http://www.wangz.net/gsqlparser/sqlpp/sqlformat.htm
>>On May 15, 10:50 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
CoreyJansen wrote:
Jerry's approach results in a "cartesian explosion."
>
Then you have a broken database server. You need to report
that as a bug to MySQL ASAP. A lot of people depend self-
join queries like this!
Again, put up or shut up. Let's your evidence that this ia a bug. Oh
that's right, you haven't got any!
Crackpot.
F'ing idiot.
Oh of course, anyone who tries to help you and correct your error is
an "idiot!"
Mitch
Jerry's a brilliant guy. Disregard this false and rude post please.
Mitch
On Thu, 22 May 2008 01:52:44 -0500, Mitch Sherman
<mi***********@hush.aiwrote:
>On Thu, 22 May 2008 04:39:17 GMT, Tim Roberts <ti**@probo.comwrote:
>>No, in this case, Jerry is right and you are wrong. In strict ANSI SQL,
any column reference in the HAVING clause must either be part of the result
set or one of the grouped columns. "groupid" is not present in the result
set, nor is it grouped.
No, in SQL-92, aggregate functions like SUM and COUNT in the HAVING
clause may reference source columns, so this query is valid:
"Each <column referencecontained in a <subqueryin the <search
conditionthat references a column of T shall reference a
grouping column of T or shall be specified within a <set function
specification>."
This quote I pasted is irrelevant... That's about subqueries. You have
to look elsewhere to find the other one...
Mitch
Disregard the foolish the posts I made before Jan 2 in this thread.
Looks like I didn't understand the replies made by others!
Mitch
On Mon, 02 Jun 2008 13:28:46 -0500, Mitch Sherman
<mi***********@hush.aiwrote:
>On Tue, 13 May 2008 12:02:59 -0400, Jerry Stuckle
<js*******@attglobal.netwrote:
>>>Not necessarily. What happens if he has two entries with (2,30)? It
will fail.
As I said - there was nothing in the original problem description to
prohibit it. And the correct answer doesn't require unique entries.
Sorry Jerry, I see that you're correct in this thred. I didn't mean to
suggest otherwise. The correct answer should work with duplicates or
without. Peter's answer is designed to work in a limited scenario.
Your answer (with DISTINCT as you said) is a better response.
Thanks for your help in understanding this SQL issue. I can see you
have a lot of experience in this area which helps to understand how to
properly model these problems.
Thanks again for your expert SQL recommendations in this thread and
many others.
Mitch
On Thu, 15 May 2008 21:49:03 -0500, Mitch Sherman
<mi***********@hush.aiwrote:
>
Your script doesn't test the same scenario at all. The table you
created is guaranteed not to have any duplicates because you defined a
PRIMARY KEY. This is exactly what you've been arguing against doing
all this time, so you've basically demonstrated why uniqueness is a
good thing.
Mitch
No I was wrong, Jerry's test shows another reasonable scenario which
the poster could be using and is a valid test of the original problem.
It's a counterexample to petersprc's original answer. petersprc's
answer needs to be modified as shown elsewhere in this thread to work
with Jerry's scenario.
Mitch
On Wed, 14 May 2008 03:32:01 -0500, Mitch Sherman
<mi***********@hush.aiwrote:
>On Tue, 13 May 2008 12:02:59 -0400, Jerry Stuckle
<js*******@attglobal.netwrote:
>>Mike Lahey wrote:
>>That was addressed in the response, but it looks like you missed it.
You make the mistake of assuming the data is not normalized. I think the
point of Peter's post was to ensure that the data was indeed normalized.
Which, if it is not normalized, will not work.
As I said - there was nothing in the original problem description to
prohibit it. And the correct answer doesn't require unique entries.
That's impossible if you have a unique index as the poster stated.
In a classic one-to-many (1:N) relationship, you shouldn't have any
duplicates. The recommendation to normalize your data is sound advice
which you seem to be disagreeing with.
The query you're suggesting will incorrectly overstate the number of
unique entries matched if there are duplicates. You should use "SELECT
DISTINCT" in that case.
Jerry already pointed out you can use DISTINCT if you want to remove
dups so I think I missed his point again. His query is correct
Mitch
Mike Lahey wrote:
He said entries belong to categories, which is a fairly obvious
relationship. This is a binary relation. Thus there must exist a 2
column relational table in this design, or it's not normalized. Yes,
other tables may exist, but it's not relevant.
Yes well I was wrong in the post I'm replying to as well. Jerry's
scenario is totally consistent with the poster's scenario.
Mike Lahey wrote:
It's a red herring because
This post was very rude. Please disregard it.
Mike Lahey wrote:
This was a rude post and I was wrong. Please disregard it.
On May 12, 10:55 am, aguillacu...@gmail.com wrote:
On May 12, 9:20 am, Captain Paralytic <paul_laut...@yahoo.comwrote:
On 12 May, 02:36, Mike Lahey <mikey6...@yahoo.comwrote:
Pay attention to the posts. Peter's solution will work.
It may work, but that does not make it the "correct" way to do it.
Oh no, the answer is correct, but there are alternatives.
Well my post was not quite accurate. The answer wasn't correct it
imposed an unnecessary restriction - that the 2 columns couldn't have
duplicates. However, the answer is still useful if your data fits that
model and you want to intersect arbitrary #'s of groups.... This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Chuck100 |
last post by:
I'm having problems with the output of the following script (I've
simplified it):-
select a.section,a.user,count(b.number),null
from table a, table b
where.........
group by a.section,a.user...
|
by: Franklin P Patchey |
last post by:
I have modified some script and think i have put a bit in that isn't
"compliant"
Is the bit marked below (towards the end) correct - should it be () and not
("")
<SCRIPT LANGUAGE="JavaScript">...
|
by: ASallade |
last post by:
Hello,
I've scoured my books and the web, but am still daunted, hopefully some of
the users in this newsgroup will have advice for my problem.
I am not an experienced javascript programmer,...
|
by: Funnyweb |
last post by:
When adding a field to a table using ALTER TABLE is it possible to check if
the field already exits before the ADD command is run? If so how do I do
this?
Thanks
Hamilton
|
by: JPL Verhey |
last post by:
(i hope somebody (else) will read and have an idea! Thnx)
Hi,
With a script in a popup window, I want to check if certain content is
present in a page loaded into the frame "main" of the...
|
by: Rahul |
last post by:
Hi Everybody
I have some problem in my script. please help me. This is script file.
I have one *.inq file. I want run this script in XML files. But this
script errors shows . If u want i am...
|
by: gunimpi |
last post by:
http://www.vbforums.com/showthread.php?p=2745431#post2745431
********************************************************
VB6 OR VBA & Webbrowser DOM Tiny $50 Mini Project Programmer help
wanted...
|
by: adamurbas |
last post by:
ya so im pretty much a newb to this whole python thing... its pretty
cool but i just started today and im already having trouble. i
started to use a tutorial that i found somewhere and i followed...
|
by: koutoo |
last post by:
I have a code that writes to 2 seperate files. I keep getting a "list
index out of range" error. The strange part is that when checking the
files that I'm writing too, the script has already...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
