Steve,

If you had a database that did not have a keyed field, what
would be the best way to request a random record?

I've already figured a way to generate a random number from
one to the number of records in the database. But I'm not sure that's
going to here.

Any ideas?

Regards,



Fred

On Sun, 10 Feb 2008 01:36:05 +0100, Fred Atkinson <fatkinson@mishmash.com>
wrote:

> Steve,
>
> If you had a database that did not have a keyed field, what
> would be the best way to request a random record?

SELECT .... ORDER BY RAND() LIMIT 1
--
Rik Wasmus

"Fred Atkinson" <fatkinson@mishmash.com> wrote in message
news:1khsq3p3grqhtgepom2g43gvunkbimpedd@4ax.com...
> Steve,
>
> If you had a database that did not have a keyed field, what
> would be the best way to request a random record?
>
> I've already figured a way to generate a random number from
> one to the number of records in the database. But I'm not sure that's
> going to here.
>
> Any ideas?
>
> Regards,
>
>
>
> Fred

What is a non-keyed database? Do you mean no primary key or no indexes?

Evan

On Sat, 9 Feb 2008 20:22:18 -0500, "Evan Keel"
<evankeel@sbcglobal.net> wrote:

>
>"Fred Atkinson" <fatkinson@mishmash.com> wrote in message
>news:1khsq3p3grqhtgepom2g43gvunkbimpedd@4ax.com.. .
>> Steve,
>>
>> If you had a database that did not have a keyed field, what
>> would be the best way to request a random record?
>>
>> I've already figured a way to generate a random number from
>> one to the number of records in the database. But I'm not sure that's
>> going to here.
>>
>> Any ideas?
>>
>> Regards,
>>
>>
>>
>> Fred
>
>What is a non-keyed database? Do you mean no primary key or no indexes?
>
>Evan
>
Neither.

I just want to randomly grab a record out of the database.

Regards,



Fred

On Sun, 10 Feb 2008 01:45:56 +0100, "Rik Wasmus"
<luiheidsgoeroe@hotmail.com> wrote:

>SELECT .... ORDER BY RAND() LIMIT 1

Thank you,

That worked BEAUTIFULLY.

Regards,



Fred

Fred Atkinson wrote:
> On Sat, 9 Feb 2008 20:22:18 -0500, "Evan Keel"
> <evankeel@sbcglobal.net> wrote:
>
>> "Fred Atkinson" <fatkinson@mishmash.com> wrote in message
>> news:1khsq3p3grqhtgepom2g43gvunkbimpedd@4ax.com...
>>> Steve,
>>>
>>> If you had a database that did not have a keyed field, what
>>> would be the best way to request a random record?
>>>
>>> I've already figured a way to generate a random number from
>>> one to the number of records in the database. But I'm not sure that's
>>> going to here.
>>>
>>> Any ideas?
>>>
>>> Regards,
>>>
>>>
>>>
>>> Fred
>> What is a non-keyed database? Do you mean no primary key or no indexes?
>>
>> Evan
>>
> Neither.
>
> I just want to randomly grab a record out of the database.
>
> Regards,
>
>
>
> Fred
>

Fred,

It should be very rare you don't have a primary key on a table (except,
perhaps, for a many-to-many link table, but even that typically has a
primary key).

You almost always need a way to uniquely identify a row in a table
should you need to update or delete it.

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

On Sat, 09 Feb 2008 22:03:59 -0500, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>Fred,
>
>It should be very rare you don't have a primary key on a table (except,
>perhaps, for a many-to-many link table, but even that typically has a
>primary key).
>
>You almost always need a way to uniquely identify a row in a table
>should you need to update or delete it.

I do have a way to identify the row. It is a callsign. It's
almost unique except that callsigns like W5YI have two different URLs
in them (www.w5yi.com and www.w5yi.net). In that case, there are two
entries for the call.

Thanks for your feedback, Jerry, as always.

Regards,




Fred

Fred Atkinson wrote:
> On Sat, 09 Feb 2008 22:03:59 -0500, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
>
>> Fred,
>>
>> It should be very rare you don't have a primary key on a table (except,
>> perhaps, for a many-to-many link table, but even that typically has a
>> primary key).
>>
>> You almost always need a way to uniquely identify a row in a table
>> should you need to update or delete it.
>
> I do have a way to identify the row. It is a callsign. It's
> almost unique except that callsigns like W5YI have two different URLs
> in them (www.w5yi.com and www.w5yi.net). In that case, there are two
> entries for the call.
>
> Thanks for your feedback, Jerry, as always.
>
> Regards,
>
>
>
>
> Fred
>

Fred,

Almost is not the same thing.

For instance, what happens if you change the w4yi.net to w4yi.com in the
table? How can you differentiate between the two?

I don't know what else is in the rest of your tables, but if that's a
link table (the only two things are the call sign and the url), chances
are the combination of the two should be the primary key (will keep you
from having duplicates).


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

On Sat, 09 Feb 2008 22:12:28 -0500, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>Fred,
>
>Almost is not the same thing.
>
>For instance, what happens if you change the w4yi.net to w4yi.com in the
>table? How can you differentiate between the two?

That's a point. However, I'll be the only one administering
it. I won't let that happen.

>I don't know what else is in the rest of your tables, but if that's a
>link table (the only two things are the call sign and the url), chances
>are the combination of the two should be the primary key (will keep you
>from having duplicates).

Actually, there are four fields. The only two that will be
displayed are the callsign and the url. The other two are for
functional purposes in ordering the database and trying to even out
the number of times that each call and url are displayed.

I'll see about making the two fields the index. I considered
putting a key field in but for the most part, the field would be
useless for what I am doing.

I've got a prototype script running on the database site. As
soon as my provider gets back to me about accessing the database from
another Web site, I'll be moving to another Website to run it. Since
I'm going to want to run it on multiple sites, developing it on a
separate site seems prudent. If any security problems crop up, I'll
be able to address them then.

I'm going to continue to develop the new script. Once I have
it perfected, I'll be importing a text file with a bunch of
callsigns/url combinations. I've got to figure a way to edit the text
file into a format that can be imported. If the file didn't have so
darned many entries, I'd just type them in myself (I did put sixty of
them at random in the database for development purposes).

Then I'm going to revise the existing script to take the data
from the database rather than the text file.

From there, I'll come up with some management scripting. It
shouldn't be hard to create text files that can easily be imported
into the database. These would be new entries that people would input
to the site.

Regards, and thanks for your comments.



Fred

On Sat, 09 Feb 2008 22:02:03 -0500, Fred Atkinson
<fatkinson@mishmash.com> wrote:

>On Sun, 10 Feb 2008 01:45:56 +0100, "Rik Wasmus"
><luiheidsgoeroe@hotmail.com> wrote:
>
>>SELECT .... ORDER BY RAND() LIMIT 1
>
>Thank you,
>
> That worked BEAUTIFULLY.
>
> Regards,
>
>
>
> Fred

I've been experimenting with that command. I've changed the
limit to higher numbers. The thing that seems to ring true (and I
hope I'm right) is that when I request several records (SELECT.....
ORDER BY RAND() LIMIT 30) that there never seems to be a duplicate
record. Am I correct in assuming that this format prevents duplicate
records from appearing in the results?

Regards,




Fred