Darren New wrote:
> Ideally, for example, you'd have no "unique
> IDs" in your database - the only reason you do is that some real-world
> items have unique properties that you can't digitize.

Hmm...

Suppose I have "tasks" (CPU-intensive processing tasks, such as rendering a 
certain frame of a certain POV-Ray scene at specified settings). I store 
those tasks in a relational table. Each task has a unique *name*.

I have another table that holds information about input files, such as the 
.pov. And a third table that links the task and file tables together, since 
it's n-to-n (a task may use multiple files, a file may be used by multiple 
tasks).

From a *practical* point of view... Should that link table refer to tasks by 
their names? It's a known unique property, and I can "digitize" it. Or 
should I add a numerical "unique ID" to the task table, and use that from 
the link table, with the purpose of needing less storage for the link table 
and making lookups faster? Heck, would integers *be* faster than strings,
if I use indexes in either case?

Post a reply to this message