Announcments in all boards!

[[Unknown]]

Your way would not be global - one board only.... that is, the OR would allow for a sticky on any ID_BOARD.

-[Unknown]

yes, using isSticky set to 2 would only allow the post to be an announcement post on the board it was written. I've done that. And it works fine, however, Nonya wants a global announcement mod. I really think it will be more involved and will probably need more than using isSticky and adding a query. As you have pointed out, that would be slower. And except for intimate moments, faster is better.

What I meant was that this query:

SELECT something
FROM somewhere
WHERE ID_BOARD=$board
 OR isSticky=2
ORDER BY isSticky DESC, posterTime DESC

Would mean that it either had to be on this board, or a global sticky... that is,

Get something from somewhere...
IF the board is the board we are looking or... or the post is on ANY board, but is a global sticky...
And return the information with stickies on top, newest first.

Thus, this would almost be the fastest way - using only one query.

-[Unknown]

[groundup]

BAM, unknown gave you 1/2 of the mod. Now all you have to do is add the option to post & modify and you are done. Or you can make it an admin option. You can do it in a lot of ways, 1 would be making the admin enter the id of the global sticky (fastest to mod).

[Dataforce]

now all thats needed is for some1 to actually make this into a proper mod thats actually useable.

VBulletin achieved it, with little or no slowing down, so YaBB should be able to aswell.

[[Unknown]]

For reference, vBulletin uses a seperate table.

-[Unknown]

[Nonya]

Almost done just give me some few days  

[Iridium]

Once again, I see phrases such as "very slow" being tossed around, without any real evidence to back such claims.

As far as I could tell from looking at the MySQL documentation, there is nothing to indicate that using OR suffers any major speed penalties (although, common sense would say that it might, as it includes records, rather than excluding them, as using AND would.)

Of course, the next obvious step is to do a vaguely-controlled benchmark.
This involved selecting (and fetching into an array, so there was some PHP overhead) 30 rows from my YaBBSE Topics table (3500 rows) based on a simple ID_BOARD=xx and timing it over 5000 such selects/fetches. This was repeated, but including an OR isSticky=1.

As one might expect, the query that included the OR term was slower, but I hasten to add, only very marginally (we're talking less than 5% in repeated runs).

At this point, I noticed that I had missed the ORDER BY clause, and so re-ran the test including that. The results were somewhat surprising: with the OR isSticky=1 it was in fact a minimum of 25% faster than without. (This is slightly misleading, seeing as the table contains quite a few stickies, and the number of global stickies is probably going to be considerably fewer than the total number of normal stickies on all boards, so MySQL wouldn't be able to optimize the sorting quite as well).

In conclusion, it'd be really nice if people wouldn't exaggerate quite so much in, what are actually, complete assumptions about relative speeds (be it queries, string concatenation, or anything else). In fact, if you're going to make such wild claims, which seem to be based on some "expert knowledge" maybe it'd be a good idea to get just the slightest bit of real evidence first, then you wouldn't look like quite such a crappity smacktard! (which, thanks to the censor, sounds almost more amusing than the intended "fucktard")

[[Unknown]]

OR _is_ very slow.

My own benchmarks....

for ($i = 0; $i < 5000; $i++)
{
   mysql_query("
      SELECT ID_TOPIC
      FROM {$db_prefix}topics
      WHERE ID_BOARD=1
         OR isSticky=1
      ORDER BY posterTime DESC, isSticky DESC");
}
Took 0.75925397872925 seconds.

for ($i = 0; $i < 5000; $i++)
{
   mysql_query("
      SELECT ID_TOPIC
      FROM {$db_prefix}topics
      WHERE ID_BOARD=1
      ORDER BY posterTime DESC, isSticky DESC");
}
Took 0.65996193885803 seconds.

As you can see, it is a large bit faster.

Regardless, I never said it was too slow, just quite slow.

-[Unknown]

[Iridium]

Well, actually your post stated:

Because OR is VERY VERY VERY slow.

When I see that, I think "my board is going to be unusable if I add this feature" (As I would imagine did the numerous other readers)

Unfortunately, your "benchmarks" are so artificial, and lacking in detail that I can't comment on them.

[[Unknown]]

Well, for the record I've been insulted enough that I won't write this mod.

-[Unknown]

[old dan]

Well, for the record I've been insulted enough that I won't write this mod.

-[Unknown]

Hey [Unknown], sorry if I insulted you, it wasn't intentional. However if you like I know some really good insults and would be willing to let you have them...................

[old dan]

Almost done just give me some few days  

Looking forward to it.

[[Unknown]]

Hey [Unknown], sorry if I insulted you, it wasn't intentional. However if you like I know some really good insults and would be willing to let you have them...................

Oh, don't worry.... you've never said anything that overly bothered me... I mean, okay some things a *little*, but not really.  What got me was this:

In conclusion, it'd be really nice if people wouldn't exaggerate quite so much in, what are actually, complete assumptions about relative speeds (be it queries, string concatenation, or anything else). In fact, if you're going to make such wild claims, which seem to be based on some "expert knowledge" maybe it'd be a good idea to get just the slightest bit of real evidence first, then you wouldn't look like quite such a crappity smacktard! (which, thanks to the censor, sounds almost more amusing than the intended "crappity smacktard")

Which was _obviously_ aimed at me.  Sorry if I tried to be of help.  Won't do it again, Iridium.

-[Unknown]

[Dataforce]

so any progress with this mod ?

[Nonya]

I'm still working , sorry i was busy the last few days i hadn't much time to complete it.
anyway,
i'll finsh it a.s.a.p  

[Dataforce]

kk gd gd \o/