RE: EDS cry out!!!! Rob, Andy Sepa, anyone]
> -----Original Message-----
> From: jordah ferguson [mailto:jorfergie03 at yahoo.com]
> sorry rob, but i'm not getting you.
> how would i copy these keys? coz the only way i know would be using
> db_insert(). what do you mean they are unique. db_find_key returns an
> integer eg1 or 3. isn't it possible it could interfere with
> other keys
> in other tables.
>
> sorry, rob. i just don't know how the database.e library
> works? I know
> how to use it and it is the key component of my application.
> please be a
> bit less technical.
What Rob is suggesting is leaving your original table untouched, and only
copy the key values to a new table. The structure of an EDS table is to
have { key, data } for each record of the table. To actually access a
record, you use db_find_key(), which returns a record number (just an index
to point to the record within the table). However, all key _values_ will be
unique within the table. Then you'll have an original table, and another
table with just the keys, that you could use to reference the old table.
You should never permanently store record numbers, since these often change
whenever a record is inserted or deleted. Only key value is
important/necessary/sufficient.
This is [sorta] how relational databases work. Records in table A can
reference records in table B using the key values of table A (thus defining
a relation between the two tables). Of course, you'll need to structure the
data in an EDS record to suit your purposes, since this isn't done for you.
By storing the data in one place, you can reduce the size of your file, as
well as eliminate errors that could be caused if data is stored in two
places, and only one is changed, etc.
The keys could, indeed conflict with other keys in other tables. Now you're
getting into database design (and probably deeper, considering EDS doesn't
really enforce a relational [or any other] scheme). Maybe if you told us a
bit more about why you're copying so many records. Do you need to do this
often, or is this an occaisional thing? Perhaps there's a better way to
organize the data.
Matt Lewis
> Robert Craig wrote:
> > No, I didn't mean to suggest that EDS would do anything
> > for you automatically or magically.
> > I just meant that since keys are unique,
> > you could leave the large chunk of data in one place, and
> > just copy the (small) key value around to various tables.
> > You could then retrieve the data any time you want by
> > the usual method: select the table, look up the record by key
> > (it's fast because it uses binary search), then access
> > the (large) data for that record.
|
Not Categorized, Please Help
|
|
