On 11/14/05, Rick Hillegas <[EMAIL PROTECTED]> wrote:
Dan's argument which is mine too I believe is in respect with users migrating from Sybase/MS SQL Server apps using TINYINT to Derby - if we provide an unsigned type by default then they don't have anything to change in respect with that type (same semantics) - MySQL has support for both SIGNED and UNSIGNED so what not have (unsigned) TINYINT supported in Derby by default and encompass a wider range of databases supporting (unsigned) TINYINT which in the end will ease migration and help Derby's adoption...
Daniel John Debrunner wrote:
>David W. Van Couvering wrote:
>
>
>
>>I thought Rick's suggestion of adding the "UNSIGNED" keyword was a good
>>solution -- we can get the best of both worlds...
>>
>>
>
>So more non-standard syntax? Why is it better for a SQL Server/Sybase
>application to change their types to TINYINT UNSIGNED, instead of
>SMALLINT?
>
Some customers may not care if they have to double the column size.
Others may care.
Dan's argument which is mine too I believe is in respect with users migrating from Sybase/MS SQL Server apps using TINYINT to Derby - if we provide an unsigned type by default then they don't have anything to change in respect with that type (same semantics) - MySQL has support for both SIGNED and UNSIGNED so what not have (unsigned) TINYINT supported in Derby by default and encompass a wider range of databases supporting (unsigned) TINYINT which in the end will ease migration and help Derby's adoption...
>Or even SMALLINT with a check constraint to limit the range.
>
>Dan.
>
>
>
You can also implement NOT NULL as a check contraint. Most databases
consider that to be an inefficiency which it's worth optimizing with
custom logic.
