by sargstuff on 3/31/2023, 8:54:52 PM
From a compiler as system environment perspective, there are a couple of approaches used:
-- 4gl languages[0] aka direct in-language support for database(s)
-- programming language library extensions for dealing with specific types of databases/database formats
-- use of a programming language's standard file/internet read/write functions to import/export formats such as ODBC,json, html and ascii delimited file(s).
by sargstuff on 3/31/2023, 10:25:35 PM
Description of types of DBMS[0], in-memory DBMS[1][2]
List of in-memory databases[3]
A DBMS not designed as an in-memory DBMS can realize in-memory DBMS benefits via being used on a ramdrive[4].
[0] : https://www.techbaz.org/blogs/dbms.php
[1] : https://en.wikipedia.org/wiki/In-memory_database
[2] : https://medium.com/@denisanikin/what-an-in-memory-database-i...
[3] : https://en.wikipedia.org/wiki/List_of_in-memory_databases
[4] : https://en.wikipedia.org/wiki/RAM_drive (* virtual environment : https://snarky.ca/how-virtual-environments-work/
vs getting around physical board space limitations :
ddr ram over pcie : https://ddramdisk.store/shop/
clx, omi : https://semiengineering.com/cxl-and-omi-competing-or-complementary/
)by sargstuff on 3/31/2023, 7:53:42 PM
** Generally, the system environment a program is started from provides the
interface to persistent/non-persistent resources used by/accessible to the
running program. Within a program, the resources provided by system environment
running the program can be interpreted/used by the running program in a way
different from the system environment.
-- The running program does not have to interpret the persistent/non-persistent
resources in the same manner as the OS. aka data file program provided by OS is
stored in windows file format on hard drive. The program can interpret the
aforementioned data in the file as something other than a windows format after
the OS has fetched the file information.
** Not clear what single category of system environment using. (OS, DB,
integrated developer environment, file editor, compiled program,
interpreted program).
** Not clear if talking about program data input sources & when/how input
sources are used. aka From command line, redirecting database query result
containing a runnable shell script as input to a command line shell.
** The system environment a program is run from can make the resources
a running program uses appear to come from something different than
where the system environment got the resources from -- aka. program
environment provides running program a file from local hard disk,
where the 'file from local hard disk' might have been fetched by the system
environment via internet connection from a cd located on a remote machine.
Virtual machines running macOS under windows is one example.
If such a thing exists or is possible, how would the performance be? I imagine the performance would be significantly degraded? Or could caching help mitigate this? If such a thing exists or could exist, how would the distinction be made between in-memory and persistent structures? For example:
A let a_xpto: i32 = 10; would place the value "10" in the memory region called "a_xpto". If it were persisted, it could be something like: ^let a_xpto: i32 = 10; which would place the binary value "10" in a key-value position with the key "a_xpto" where the "^" directive would indicate that the writing would be done in the database and not in memory.
Wouldn't such a language solve all the age-old problems we face at the interface between code and databases? I see that today we have numerous databases, each with a different purpose, a different interface, and communication between code/data structures in memory vs databases is always very painful. We're always left wondering: should we create this function in the database or in the code? How would the performance be? And if I have more than one type of database? How do I integrate them? Should I load everything into memory to filter? Or should I filter something in the database before processing further?
Additionally, we end up with that odd-looking code that passes strings to databases. Even when using an interface that "maps" the database to objects, it's still not great. It's always a pain to modify the database, for instance. If something like what I'm describing existed, it wouldn't matter which database was behind it. I know that Datomic does something in this direction: it abstracts a database, allowing you to easily swap out the underlying database type. However, it's still not quite what I'm talking about. What I'm describing goes beyond that: you would use the same data structures, objects, etc., that you're used to working with in your code, but in a persistent manner.
Can anyone shed some light on this?