Category: Valentina SQL

[Imp] LINK/UNLINK commands now have optional suffix to suppress errors

Thorsten have point us that for his task it is not comfortable when command

LINK RECORD (1) OF T1 TO RECORDS(3, 7, 9) OF T2

throws error and stops, if link 1-7 already exists.

We have agree and improve these commands adding suffix

LINK … [IF NOT EXISTS]
UNLINK … [IF EXISTS]

This suffix is similar to CREATE/DROP commands. If it is specified, then error is not fired and command continue work for other pairs of links.

[Imp] CREATE BINARY LINK now does not accept SET NULL, SET DEFAULT by grammar. NO CASCADE added

Thorsten have point us that WIKI page about this command looks strange, because uses

Referential_action
: NO ACTION  (alias to RESTRICT)
| RESTRICT
| SET NULL
| SET DEFAULT
| CASCADE

Now SQL grammar have one more rule vext_referential_action_for_link without “SET NULL”, “SET DEFAULT” and added “NO CADCADE” for Binary Links.

Continue reading [Imp] CREATE BINARY LINK now does not accept SET NULL, SET DEFAULT by grammar. NO CASCADE added

[IMP] Recursive query now can use RDB-link defined on the fly

While Valentina have very cool syntax for recursive queries, one Valentina developer have point us that it cannot be used in his task, because he do not have predefined link with name. Taking this into account, for v5.0 we have extend syntax of recursive query

from    USING link_name
to        USING (link_name | search_condtiion)

Continue reading [IMP] Recursive query now can use RDB-link defined on the fly

Choosing appropriate database’s segment size

Each Valentina’s volume consists of set of segments, even internal service-data placed in such segments.

Database storage is implemented similar to some file system. There are volumes (.vdb, .dat, .blb, .ind, .tmp) and there are some embedded files on that volumes (all the data like field-data, indexes and so on go to that files). Each volume operates with own segment map – so we can find (and allocate new) segments for particular embedded file easy and fast.

Continue reading Choosing appropriate database’s segment size

[NEW] ORDER BY in aggregative functions First()/Last()

SQL Standard allows to SELECT only fields mentioned in the GROUP BY and expressions based on aggregative functions. You cannot SELECT a normal field. But sometimes you may very want to do this. Question is what to do in this case.

In this new Valentina Wiki article, we have describe in detail this problem and gave THREE solutions. The third solution is new for v5.0 and it works x400/ x50 times faster of the first two correspondently in tests on the database of our customer.

The third solution, uses idea from ORACLE database actually: FIRST()/LAST() functions with own ORDER BY to be used inside of each group. It seems mySQL and PostgreSQL do not have any way to resolve this task in such effective way.

[NEW] Valentina 5.0 adds Sequences.

Postgre/Oracle users are used to use Sequences to generate values of Primary Key of tables. mySQL/Access users are used to use auto increment flag on a PK field for the same task. Generally speaking Sequences are more powerful and flexible, but more verbose.

We have add Sequences into Valentina 5.0 in 99% same way as they work in PostgreSQL, so now Valentina developer can choose between auto-increment and sequences if they develop true Relational model.

You can read details here:

Reminder: If developer uses modern ObjectPtr and Binary links of Valentina DB, then he can avoid PK-FK headache at all.

 

New Docs About ENUM Type in v5.0

Today I added new reference pages to the wiki of e.g. SQL grammar about a new feature of Valentina DB for 5.0: the ENUM type.

This is the first step towards a CREATE TYPE command based on the SQL 2003 standard. Next we can add composite types, collection types and inheritance.

We think that Valentina can have a more effective and flexible ENUM implementation compared to PostgreSQL or mySQL. One example is that Valentina can use 1 byte to store an enum value, while mySQL – 2, PostgreSQL – 4.

We are finishing now integration of this feature into Valentina Studio for both Valentina DB and PostgreSQL plugins. Database types in Valentina Studio are supported through a plugin architecture.

These are major entry points in the Valentina Wiki to check:

[TIP] Protection from SQL Injection Attack.

This tip is expired by article two-steps-forward-to-more-secure-applications. The First part of the article discusses  SQL Injection Attack and how to develop code protected from it.

After read of the article you will know that to easy way for protection – is usage of SQL binding. Wow? One more reason to ALWAYS use SQL binding!  Other well known reason are

  • reduces CPU time as for client so for server, because no string concatenations on the client side, and less job for parser on the server side.
  • enables usage of Query Pool, because SQL command is the same byte to byte.