A column oriented database system or table such as in jd has each field stored
as a list, and independently of each other.
A common conceptualization of a database table is a 2d structure with fields
and records. Keys on a table (or dictionary) are unique to each record/row
A dictionary is just a table with 2 fields. One of which is a key. (the other
value)
The internal structure of my table/dictionary class would be one variable for
each field.
On Wednesday, November 20, 2019, 11:39:52 a.m. EST, Raul Miller
<rauldmil...@gmail.com> wrote:
This might be better on the chat forum, but:
(1) "table" -- we've got lots of existing uses of that term. For
example: https://www.jsoftware.com/help/dictionary/samp07.htm
Specifying a table as "just a dictionary with ..." could conflict
with those uses (existing tables have rank and shape. But what's the
shape of a dictionary?
(2) I can't make heads nor tails of "A dictionary is a table with just
one key and 1 value."
And I just get completely lost after that.
Use cases (or: useful examples) are probably what we need here.
Thanks,
--
Raul
On Wed, Nov 20, 2019 at 11:04 AM 'Pascal Jasmin' via Programming
<programm...@jsoftware.com> wrote:
>
> Here are the goals I have for a dictionary class.
> A table is just a dictionary with (potentially multiple) key(s) and multiple
> values. A dictionary is a table with just one key and 1 value.
> Underlying storage should be at the most performant data type: If all keys
> or value (columns) are of the same/compatible types then they should be
> stored as such types. Only boxed if the "field" contains incompatible types.
> Object creation of the table/dictionary can impose type and shape
> restrictions.
> To accomplish the above, a list class that boxes items only when an item
> incompatible with the rest of the list is added is needed. Then columns just
> use that class interface to add/update values.
> The tradeoff is append/update checks/slowdowns in order to be able to obtain
> "clean" raw data/columns, but also avoid boxing if checks allow it. The
> checks may have less of a performance penalty than "upserting"
> (append/update) boxed structures.
> restricting types of table/dic at creation, further eliminates the checks,
> relying on errors when an incompatible type is added.
> An alternative simpler design is to have separate classes for
> dictionary/table maintained with boxed items, and one with raw items. Most
> applications do not require variable field types. Types and shape(with fill)
> restrictions can still be added at creation time in order to coerce values to
> that type. For boxed storage, items are boxed without checks. So both class
> types have better performance.
>
> sugar functions for trimming variable shape columns (such as strings) make
> sense, and a default numeric list fill value of __ may be better than 0. _.
> is an option for fill value, but may harm performance more. __ or _. instead
> of 0 makes a floating point datatype storage though. Using a magic
> MAX/MIN_int would solve this, but create a bug in someone sometime's
> application that would be hard to track.
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
