[gl00mie]

Цитата:

Сообщение от axstart

can you provide me some more invormation about your replay

Well, the idea is that a DBMS (Ms SQL Server or Oracle DS) doesn't care about DAX caching improvemets - it still distinguishes between PRIMARY KEY (which can be set from MorphX via a corresponding table property) and UNIQUE constraints (which can be set from MorphX via a table index property). Of course if we take into account that DAX neither uses itself (except for RecVersion field value since AX 3 KR3) nor allows to use from X++ NULL table field values, then PRIMARY KEY and UNIQUE constraints differences merely vanish. But still there can be scenarios when you use some tables in a DAX database for a data exchange with a foreign system and enforce a FOREIGN KEY constraint on some other tables involved in the exchange. Obviousely you'll need a primary key for this as none of unique keys will be suitable for such a scenario. And it would be handy to declare a primary key on your DAX table from MorphX rather then altering it from a DBMS side and dealing with AOT Data Dictionary synchronization issues when DAX simply drops all indexes/constraints that are not declared in AOT.

Цитата:

Сообщение от axstart

to my opinion SQL has no primary thing at all...

It seems this statement is not quite correct.

PS. There's a good book «Expert one-on-one Oracle» by Tom Kyte where he's stressing one idea: don't use a DBMS as a "black box"; if your application relies on a database - learn the DBMS you're using otherwise your project is most likely doomed to be non-scaling application with not more then several concurrent users. DAX is the system that relies on a database so even if DAX moves from ternary SQL logic (value matched - value not matched - value is NULL) to a binary logic (value matched - value not matched) which makes PRIMARY KEY and UNIQUE constrains not so different, you still can't just ignore the underlying DBMS that doesn't care about assumptions and simplifications introduced in your system.