You are not logged in.
Pages: 1
Hi ab,
I want to declare boolean and varchar data types in my tables. And here is my model :
TFinancialYears=class(TSQLRecord)
private
fEndDate: TDateTime;
fClosed: Boolean;
fClosedByUserId: Integer;
fStartDate: TDateTime;
fCloseDate: TDateTime;
fCompanyId: integer;
published
property CompanyId: integer read fCompanyId write fCompanyId;
property StartDate :TDateTime read fStartDate write fStartDate;
property EndDate :TDateTime read fEndDate write fEndDate;
property Closed:Boolean read fClosed write fClosed;
property ClosedByUserId:Integer read fClosedByUserId write fClosedByUserId;
property CloseDate :TDateTime read fCloseDate write fCloseDate;
end;
But when the table is created in SQL Server, Integer types will map to int64, rawutf8 will map to nvarchar and boolean types will map to integer.
How can I declare exactly the same type as equal type in SQL Server in Delphi?
Thanks.
Offline
The Boolean type is not handled by our SynDB layer.
So it is not possible to let the ORM create such columns.
You can try to create the table manually by SQL - I guess boolean columns may work with the ORM, but it will depend on the DB client itself....
Note that using an integer field could help your DB to evolve, if later on you switch from a boolean to an enumerate, to have more than 2 states.
If you really need a boolean column... then you are focusing on SQL, not objects, so perhaps you have to consider what an ORM is about.
Offline
Thanks a lot.
Is it possible to create varchar or integer field type? not nvarchar or int64.
Why mORMot doesn't support boolean type?
Last edited by Hmdsadeghian (2018-08-01 17:07:47)
Offline
There is a good answer on stackoverflow for this question https://stackoverflow.com/questions/114 … ase-design
Integer column with 0/1 value is the best choice for storing boolean to RDBMS imho
Offline
Thanks for your answer. from Performance perspective , the length of a record is smaller is better. because more rows can be saved on a page that is 8kb.
In the systems with high transactions , data types must be very precise.
Offline
Your assumptions about DB was correct in 1980's but DB storage engine did change a lot since!
A BIGINT doesn't take more than a byte, in some DBs.
Even CLOB (nvarchar(max)) are faster and uses less space than size-specific fields in modern DB today.
See e.g. https://www.postgresql.org/docs/current … acter.html and the performance note.
Offline
Your assumptions about DB was correct in 1980's but DB storage engine did change a lot since!
A BIGINT doesn't take more than a byte, in some DBs.Even CLOB (nvarchar(max)) are faster and uses less space than size-specific fields in modern DB today.
See e.g. https://www.postgresql.org/docs/current … acter.html and the performance note.
?? thats a PG thing only and just an advantage for updates iirc. This has nothing todo with "modern". An index scan is getting slower here as a side effect.
Offline
Pages: 1