> I asked the Presenter of the "Database Design Fundamentals"
> presentation at MAX last week, and she replied the both
> methods are acceptable and equal in regards to performance in
> any DBMS system she was familiar with. So, it is just a
> choice of style on which you prefer.
There is one
I think Keith answered your questions about my example as good or better then I
could. His example is a concrete real world example, where as mine was mostly
a pseudo code concept of an example.
I would just add one thing to try and clarify something that may be confusing
at first. There are
Roberto Perez wrote:
> At 12:38 PM 11/11/04, Ian Skinner wrote:
>
>>I don't know how unique the url's are in your data, but if any of them
>>are repeated you would probably want an "URL" table.
>
> Actually, that is correct. Some URL's may be good for more than 1 word. I
> was just thinking of
Part of the database. I'm not sure where you do it in Access, if
you're sticking with that.
cheers,
barneyb
On Wed, 10 Nov 2004 23:09:40 -0500, Roberto Perez <[EMAIL PROTECTED]> wrote:
> At 01:25 PM 11/11/04, Deanna Schneider wrote:
>
> > And, if you
> >index on the foreign key, the database w
At 01:25 PM 11/11/04, Deanna Schneider wrote:
> And, if you
>index on the foreign key, the database will be able to retrieve the related
>records without doing a full table scan.
Thanks for the answer. So, the indexing of the foreign key (also mentioned
by Keith) is something I would do intern
At 12:38 PM 11/11/04, Ian Skinner wrote:
> I don't know how unique the url's are in your data, but if any of them
> are repeated you would probably want an "URL" table.
Actually, that is correct. Some URL's may be good for more than 1 word. I
was just thinking of updating them manually one by
Roberto Perez wrote:
> At 02:11 PM 11/11/04, Jonathan Bigelow wrote:
>
>
>> Building relational databases is a best practice [snipped]
>>
>>Table One would look like:
>>ID | Word
>>
>>Table Two would look like:
>>ID | WordID | URL
>>
>>You'd then write a sql statement like:
>>select words_tb.word
Your biggest potential problem is your use of Access, which is a
single-user DB. Switch to something else more capable.
I'd also advise you to normalise them by splitting it into two tables.
You lose nothing by doing so, and gain a lot of flexiblity. Lookups will
be lightening-fast as long as the
Just to add some complexity to this and really throw you for a loop, there is a
small chance you may want three tables. This would be desirable if multiple
words use the same url. I don't know how unique the url's are in your data,
but if any of them are repeated you would probably want an "UR
At 02:44 PM 11/11/04, Dave Watts wrote:
>If you don't use declarative
>referential integrity to enforce relationships between your records, your
>database becomes vulnerable to any mistakes within application code that
>might change one side of a relationship without appropriately changing the
>ot
Roberto Perez wrote:
>
> - the two ID fields should be autonumber, right?
That is probanly the easiest, but not an absolute requirement.
> - the relation should be between the "ID" field of the first table and the
> "WordID" field of the second table, right?
Yes.
> Just a thought: I underst
> Just a thought: I understand how relations between fields are
> useful in Access when you use Access exclusively to enter or
> search for data (e.g., through an Access form). However, if
> you are accessing data only via SQL statements with CFML, do
> the tables still need to be linked (relat
>>select words_tb.word, links_tb.url
>>from words_tb, links_tb
>>where links_tb.wordid = words_tb.id
>>You'd get all the results you're looking for in a single query.
Exact, althought I'd rather use a LEFT JOIN here to make sure I also get words
with no URL.
--
_
At 02:11 PM 11/11/04, Jonathan Bigelow wrote:
> Building relational databases is a best practice [snipped]
>
>Table One would look like:
>ID | Word
>
>Table Two would look like:
>ID | WordID | URL
>
>You'd then write a sql statement like:
>select words_tb.word, links_tb.url
>from words_tb, links_
I'm sure you'll get lots of replies to this, but here goes anyway.
Make it two tables. Your assumptions about why 2 tables would be bad are
mis-informed. You can still do one query (with a join clause). And, if you
index on the foreign key, the database will be able to retrieve the related
reco
Hi Roberto,
Your main drawback here is going to be the use of Access, not the additional
time required to return the results. A database server (MS SQL, MySQL, etc.)
would improve your reponse time, but if you don't have hundreds or thousands of
people hitting your application, Access should b
16 matches
Mail list logo
