I have about 300 columns named "Item1", "Item2", ... etc. I want to map these to an int[] array on my class where each column maps to one value in the array.

Is this possible?

use a usertype

and fire your DBA :-)

No, a user type does not work.

A user type still requires mapping one column to one value. What would I put in the .hbm.xml file?

<property name="Items" column="xxx" type="test.ArrayColumns, test" />

What would I put in place of the xxx?

<property name="myarray">
<column name="item1"/>
...
<column name="itemn"/>
</property>

Thanks, but what I am trying to avoid is listing all column names, since there are so many. Any ideas?

You could try using MyGeneration to generate your mappings from the DB Schema.

But if your schema is static, then it's only 10 mins out of your life to cut/paste
<column name="item1"/> etc (per Emmanuel's post) and create the mappings.

The DBA in me says that you should (if possible) normalize your
table structure to avoid having 300+ int columns...

I dont see how normalization would help in this case. I have columns named Item1, Item2, ... Item255. Why would I split these into multiple tables? That just slows it down because now I have needless joins.

It would help by getting rid of the original problem - hundreds of int columns in one table. Which is the lesser of two evils - you decide. Given that the columns have an identical base name "Item" and only vary by a number at the end (kinda like a primary key), it seems like a one-to-many or many-to-many relationship would make more sense. Most database systems do relationships very well, hence the term "relational" in RDBMS. Is there a business domain reason against using relationships other than the perceived slowness?

You might be right but its too late to change that now.

Have you looked at using a <dynamic-component> mapping? That will map it to an IDictionary rather than an array, but isn't that better than defining 100 properties on your class?

I tried searching for google on that and I only found some source code and some very obscure and complex references to it.

Yes I've never tried using it before and my interpretation of the documentation could certainly be wrong. I guess you'll need to just give it a try and see what happens.

You are absolutely right from a design standpoint, but unfortunately there's such thing as performance. A classical one-to-many solution results in multiple joins. As a result the performance degrade significantly.

I've been having the same problem and had to redesign my data model to use the same "Item1", "Item2"... layout to avoid those joins. At the moment I believe I reached a compromise by using one-to-many between the "master" record and "item pools" - records, containing 10 columns (Item1, Item2,...) each. This way it is more flexible, and I am not limited by say 100 columns.

Now, the hibernate aspect. For one, you can use <dynamic-component>. For me it didn't work as I'm using Hibernate annotations, which do not support it yet. So I ended up with creating a composite user type, which allows you to map your attribute to multiple columns. Works pretty well, and there's no significant drop in performance.