Muldis-D-Manual

 view release on metacpan or  search on metacpan

archives/Muldis_D_PDAFP_200807_updated.xul  view on Meta::CPAN

"is_identical" treats any
differences in case or
marks or whitespace as
significant, and so any
derived ops like relational
joins and unions do also
----
If one wants, for example,
case-insensitive matching,
they must explicitly
normalize the operands in
question to the same case
----
Muldis D works with text
at the highest Unicode level
of abstraction, in terms of
language-independent
graphemes, so the codepoints
used are not a logical
distinction for identity
----
With numeric data, Muldis D
treats even floating-point
derived values as exact
values; "is_identical" will
only result in TRUE if all
bits of the significand and
exponent are the same
----
If one wants, for example,
approximate matching such as
just on significant figures,
they must explicitly round
the operands to remove the
insignificant portions
----
Muldis D is type safe and
strongly typed; there is no
implicit / automatic
sideways type conversion or
casting; for example, from
a Rat to an Int or from a
number to character data
----
Tuples in a relation are
always identified by the
values of their explicitly
defined attrs; there are no
special implicit extra attrs
like an automatically
generated SQL "row id"
----
Virtual reality
----
A fundamental feature of a
relational database is that
multiple perceptions of the
same data can exist at once;
each user can perceive the
same data being organized
according to their own prefs
----
Even if the actual means of
storing data changes over
time, users continue to be
able to perceive it in the
same ways as before the
change
----
In Muldis D, an attr of a
var can itself be treated as
a var; if the latter is
updated, the actual effect
is to update the former to
the same value it had but
for one changed attr value
----
The most significant example
of this feature is that an
entire database is really
just a single tuple variable
whose attributes are all
relations (or databases);
the relvars are virtual
----
The SQL concept of multiple
schemas in a database, as
namespaces for organizing
tables, is realized in
Muldis D with DB attrs being
themselves databases, whose
attrs are relations
----
The SQL concept of viewed
tables versus base tables is
represented in Muldis D by
declaring special functional
dependencies between several
database relvars, using
mapping functions
----
The "virtual" relvars are
defined that their values
can always be generated,
using the mapping functions,
from other relvars, so
updates to the latter always
result in upd to the former
----
As with SQL's views, such
"dependent" virtual relvars
are sometimes directly
updateable, such that their
"determinant" base relvars
are also updated, and
sometimes they're read-only
----
This same virtual attribute
concept also applies to
tuples in general, so the
same Muldis D feature covers



( run in 2.310 seconds using v1.01-cache-2.11-cpan-364913b4093 )