A table in a column oriented database system has one key for each column. If keys on each row/record are actually unique, then you don't have a table, you have a collection of unrelated rows (though, in practice, you might synthesize something that behaves like a table by repeating the same keys in every row - here, the keys are repeated rather than unique).
Maybe it would be better to model critical parts of concepts with J? Thanks, -- Raul On Wed, Nov 20, 2019 at 12:28 PM 'Pascal Jasmin' via Programming <[email protected]> wrote: > > 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 > <[email protected]> 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 > <[email protected]> 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
