db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joel Rosi-Schwartz <Joel.Rosi-Schwa...@Etish.org>
Subject Re: SQL/DDL Limitations (and DB2)
Date Tue, 21 Sep 2004 12:30:29 GMT
On Monday 20 September 2004 21:40, Satheesh Bandaram wrote:
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
>   <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
>   <title></title>
> </head>
> <body bgcolor="#ffffff" text="#000000">
> I did some searching on the internet. I found this table about some of
> the DDL maximum lenghts. (Haven't verified) If Derby increases
> constraint name length to 128, looks like it would break application
> migration to both Oracle and DB2, the top two enterprise databases.<br>
> <br>
> While increasing the limit makes life easier to migrate applications to
> Derby, wouldn't it make it harder to migrate out of Derby to enterprise
> databases? Being a free Apache product, Derby might actually have to
> pay attention to both migration routes ...<br>
> <br>
> Satheesh<br>
> <br>
> <table border="1" cellpadding="2" cellspacing="2" height="191"
>  width="536">
>   <tbody>
>     <tr>
>       <td valign="top"><b>Identifier maximum length (characters)</b><br>
>       </td>
>       <td valign="top"><b>Oracle 9</b><br>
>       </td>
>       <td valign="top"><b>DB2 8.1</b><br>
>       </td>
>       <td valign="top"><b>SQL Server 2000</b><br>
>       </td>
>     </tr>
>     <tr>
>       <td valign="top">Table name length </td>
>       <td valign="top">30<br>
>       </td>
>       <td valign="top">128<br>
>       </td>
>       <td valign="top">128<br>
>       </td>
>     </tr>
>     <tr>
>       <td valign="top">Column name length</td>
>       <td valign="top">30<br>
>       </td>
>       <td valign="top">30<br>
>       </td>
>       <td valign="top">128<br>
>       </td>
>     </tr>
>     <tr>
>       <td valign="top">Constraint name length<br>
>       </td>
>       <td valign="top">30<br>
>       </td>
>       <td valign="top">18<br>
>       </td>
>       <td valign="top">128<br>
>       </td>
>     </tr>
>     <tr>
>       <td valign="top">Index name length </td>
>       <td valign="top">30<br>
>       </td>
>       <td valign="top">128<br>
>       </td>
>       <td valign="top">128<br>
>       </td>
>     </tr>
>     <tr>
>       <td valign="top">Number of table columns<br>
>       </td>
>       <td valign="top">1000<br>
>       </td>
>       <td valign="top">255<br>
>       </td>
>       <td valign="top">1023<br>
>       </td>
>     </tr>
>   </tbody>
> </table>
> <br>
> Jason Rimmer wrote:<br>
> <blockquote cite="mid414DC322.2000102@irth.net"
> type="cite">&nbsp;&nbsp;&nbsp;&nbsp;While a reasonable suggestion
on its
> face adoption puts Derby on a slippery slope.&nbsp; Why favor DB2?&nbsp;
> Why not add transition flags for any 'enterprise-class' database such as P
> determine a destiny of its own. (Though I understand that such a
> determination could lead to the
> maintenance of these DB2 compatibility flags).
>   <br>
This is a good point. We should also be taking into account, however, of how 
this issue effects prospective legacy user applications. For example, I think 
that Derby would make the perfect default database for Jira. I run Jira in 
house and I was planning on replacing my Mckoi database with Derby. A quick 
look at the entity defs for Jira changed my mind. They do not have support 
for DB2 and it would be bit painful to go through all of the constraint names 
and redo. I any case more than I was willing to bite off at the moment. How 
many other existing applications are there that would otherwise find it 
attractive to use Derby. Possibly the answers is to use Oracle limits as the 
high side. I think most packaged applications could live with that.
> &nbsp;<br>
> Joel Rosi-Schwartz wrote:
>   <br>
>   <blockquote type="cite">I am just guessing that IBM would be less
> than overjoyed if Derby lost its ability to be an easy migration path
> to DB2. Would it not be fairly reasonable, however, to fulfil both
> requirements. At database creation time a flag could be set to dictate
> DB2 mode or extended mode. The database could then set an immutable
> database level property and behave accordingly. True this would
> introduce some complexity into the system, but it would be politically
> sensitive while still achieving better functionality.
>     <br>
>     <br>
> - joel
>     <br>
>   </blockquote>
>   <br>
> </blockquote>
> </body>
> </html>


Mime
View raw message