|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |