db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Java Class in Derby Table column?
Date Mon, 11 May 2009 13:48:06 GMT
Hi Jim,

Some responses inline...

Jim Crowell wrote:
> Rick,
>   
>> 	You can always store an arbitrary object in a Derby VARCHAR FOR BIT DATA 
>> 	column. You just have to write your own serialization logic to turn your 
>> 	TreeMap into a byte[] and vice versa. Your table would look something 
>> 	like this: 
>>     
>
>   
>> 	create table AddressBook 
>> 	( 
>> 		encodedName varchar( 1000) primary key, 
>> 		personalDetails varchar for bit data( 32672 ) 
>> 	) 
>>     
> Interesting, thanks.
>
> My Java stand alone project is a “Form Centric” Java kernel tool kit
> [jFormTK].
> The aforementioned Address Book is just an embedded Data Base of the JFormTK
> package.
>
> The JFormTK nucleus is the form field class [JFormField]. The package
> contains a set of Application forms [JFormForm] that host a set of fields.
> Each form has two classes to define the form specific information
> [JFormInfo] and state parameters [JFormForm].
>
> Presently all the above classes are stored in HDD flat files. To do so I
> have written ‘toString’ methods to convert the class parameters to delimited
> Strings. There are associated Java Constructors designed to instance the
> classes when reloading from the HDD.
>
> I believe this is akin to serialization marshalling  and unmarshalling.
> Do you agree or am I missing something about Java serialization?
>
> If you agree, it would be an easy transition to convert my “Saved Strings”
> to an array of bytes.
>   
If you can already serialize your objects to a string format, that's 
great. You can store your objects in a "varchar" column instead of a 
"varchar for bit data" column.
> One question about your sample table.
> Why “data(32672)?
> I know that 32,767 = 2 to the 14th and assume some linkage there to control
> the storage somehow?
>   
You can also use the BLOB and CLOB data types if you need to store 
really large objects (up to 2GB in size). However, the smaller datatypes 
have some extra features:

1) You can index and sort on them. This can be useful if your serialized 
form can be ordered or grouped in a meaningful way.

2) You can pass the serialized values to functions and procedures. This 
can be useful if you want to use these columns in check constraints, 
generated columns, and triggered procedures.

Right now, Derby does not let you sort BLOB/CLOBs or use them as 
function arguments.
> One question about overhead?
> My JFormTK Kernel is a data entry system where, i believe, the time to read
> / write marshall / unmarshall to the HDD file system is miniscule compared
> to the data entry processing. I assume that the time to read / write
> marshall / unmarshall to a Derby Data Base will be the same or hopefully
> less than the current HDD implementation.
>   
I don't see any extra overhead here other than the overhead which you 
incur by using a transactional store rather than a flat file system.
> Before I received your reply I was investigating relational object Data
> Base’s such as JODB, MYOOP and DBn0. As stated above I believe I can afford
> the Derby overhead. However, I do not really need the SQL capability since
> I’ll primarily be emulating Java TreeMap’s in my Data Base implementation
> [similar to the Address Book example above].
>   
I don't have experience with these products so I can't advise you here. 
The major alternative to single-column storage is to use one of the 
object relational mapping frameworks like JPA. Apache has an 
object-relational mapping framework called Open JPA: 
http://openjpa.apache.org/ Many people on this list use Hibernate for 
shredding objects into tuples. This approach has some advantages over 
storing whole objects in columns:

A) Incremental update. It can be significantly faster if you just need 
to update a small piece of a large object graph.

B) Portability. Generally these frameworks are agnostic about what the 
underlying database is. That makes it easier to migrate your application 
from Derby to, say, Oracle or DB2 later on.

C) Extensibility. The more granular the data, the easier it is to write 
new queries against it as your application evolves.

D) Dependencies. The more granular the data, the easier it is to track 
and maintain dependencies among your objects.

Hope this is helpful,
-Rick
> I do not know about the maturity, footprint size and deployment capabilities
> of the above Object Data Base’s but I was wondering if any of the above Data
> Base’s would be a better fit for my situation.
>
> I really like Derby and would have to have a strong reason to go to an
> Object Data Base but I’m just trying to keep pace with whatever is out
> there!
>
> Another Object Data Base consideration should be my desire to eventually
> make this Java stand alone data entry processing "persistent". In my brief
> study of the above Object Data Base's, I saw that some seem to offer a
> persistence feature.
>
> I am somewhat of a control freak and I am thinking of doing my own
> "persistence" implementation. I already have hooks in JFormTK. Each time the
> end user enters a TAB or RETURN/ENTER key I am doing some processing. For
> the aforementioned Address Book, I could easily add key listeners to code
> persistent field processing.
>
> Any thoughts on 'persistence' in Derby OR the Object Data Base's would be
> appreciated.
>
> SORRY for the length of this response.
> I have a tendency to get to detailed sometimes trying to phrase a question.
>
> Many Thanks, 
> Jim... 
>
>
> Rick Hillegas-2 wrote:
>   
>> Hi Jim,
>>
>> You can always store an arbitrary object in a Derby VARCHAR FOR BIT DATA 
>> column. You just have to write your own serialization logic to turn your 
>> TreeMap into a byte[] and vice versa. Your table would look something 
>> like this:
>>
>> create table AddressBook
>> (
>>     encodedName varchar( 1000) primary key,
>>     personalDetails varchar for bit data( 32672 )
>> )
>>
>> Let me know if I'm being cryptic here. I'd be happy to explain this 
>> solution in greater detail if you think it is useful.
>>
>> Hope this helps,
>> -Rick
>>
>> Jim Crowell wrote:
>>     
>>> Hello,
>>> I am developing a Java Stand Alone Application. Presently the data
>>> entered
>>> is saved in HDD files of the host. Soon I will be changing the HDD files
>>> structure to the Apache Derby  Data Base. I am commencing to layout the
>>> Data
>>> Base tables.
>>>
>>> For my Address Book feature I have implemented a Java TreeMap component
>>> with
>>> the following “Ordered Pairs”:
>>> ‘key’
>>> Encoded String to uniquely identify the person name.
>>> ‘value’
>>> A custom Java Class that contains the person’s control, contact info and
>>> personal info. The contact info and personal info parameters are
>>> maintained
>>> in their own custom Java Classes.
>>>
>>> Question:
>>> Basically I would like to place the Java TreeMap into a Derby  table and
>>> update just the appropriate “Ordered Pairs” as they are entered by my end
>>> user. end.
>>>
>>> Can I setup a 2 column table as follows:
>>> ‘Column 0’		The TreeMap ‘key’, i.e. the encoded person name.
>>> ‘Column 1’		The custom Java Class.
>>>
>>> I am using Java 1.5x, Eclipse and Win XP Pro development platform.
>>> I am also testing on a Mac OS X 10.5 [Leopard] node.
>>>
>>> Regards,
>>> Jim Crowell...  
>>>
>>> -----
>>> Regards,
>>> Jim...
>>>   
>>>       
>>
>>     
>
>
> -----
> Regards,
> Jim...
>   


Mime
View raw message