Tag: database

HANA, SPARK and Redis are commonly used in-memory databases, but they all have complex and heavy frameworks, compromising their ranges of applications. The popular simple and lightweight in-memory technology is SQLite, which is nimble and simple-framed and can be directly embedded in a Java program. Its disadvantages include lack of independent services and support for stored procedures, unstable environment and slow execution, weak computing abilities, and complicated data loading process for external data use. The technology has better and more powerful embodiment – esProc SPL. The open-source Java class library has simple and agile framework, enabling it to be embedded

Intermediate tables are data tables in databases specifically used to store intermediate results generated from processing the original data – which is why they are so named. They are summary tables usually created for speeding up or facilitating the front-end queries and analysis. For some large organizations, years of accumulation results in tens of thousands of intermediate tables, which is an incredible number, in their databases, bringing great trouble to database operation and usage. The large number of intermediate tables occupies too much database storage space, putting enormous pressure on storage capacity and increasing demand for capacity expansion. But database

Why text files are slower The main reason is that there are too many data parsing actions. Let’s look at an example. Suppose we need to convert text “12345” to a binary integer in the memory. The process is like this: 1. Set the initial value of the result as 0. 2. Get character “1” and parse it into number 1; multiply the initial value 0 by 10 and plus the number 1 to get number 1. 3. Get character “2” and parse it into number 2; multiply the current result 1 by 10 and plus the number 2 to

There are more or less differences in terms of function between various types of databases. When we are trying to migrate reports from one database to another, the existing SQL containing a different set of function syntax need to be converted at the same time. Usually, a SQL data set in a report is static and fixed. As an automatic conversion is impossible, we have to modify corresponding SQL statement manually and replace the old with the new. Yet the auto-conversion of SQL in report between databases can be achieved with esProc SPL. SPL designs a set of standard SQL

Databases implement SQL in their own sets of syntax. We need to translate function syntax from one database to another so that functionally equal SQL query statements can be executed in an incompatible system. The ORM technique lets programmers convert queries to SQL of another type of database. This, in effect, is equivalent to having some degree of portability. The technique, however, is only suitable for dealing with simple SQL in OLTP scenarios. It is hard to handle the complicated SQL migration tasks under OLAP scenarios, such as the use of functions that are not supported directly by ORM and