Re: Tables without primarys key?

I agree, there are specific cases where some tables may not require any keys at all as in their design they only have a handful of records that adding a key actually makes them less efficient. There's also some cases for tables that represent bags, in those cases a key is usually required for a delete however.

Entity classes don't typically map to these types of tables, however if they do, they would need to be considered unique for the ability to provide equality and a means to delete them.

IMHO, I still find it simpler even for large systems to forget about entity management and instead use JdbcTemplate from spring. It works really well, flexible and often the same code than requires with an entity manager.

> On 10 Dec 2015, at 03:40, janpla <[email protected]> wrote:
> 
> This is a question I have asked before, but I thought I would ask it again, in a slightly different way:
> 
> Is there any good reason why NetBeans does not allow you to create entity classes from tables without a primary key?
> 
> I am talking from the perspective of J2EE, and by good reason I mean a reason that is purely technical, not one that contains references to what is considered good practice. I have a had a search on the net, and the discussions always seem to become something about "why would you create a table without a primary key when it is so easy?" - I would contest that such a question is misplaced, since many developers have to work with existing databases over which they have no design power, and which are simply made that way, be it good or bad. I tend to agree, that if I design a table, then a primary key would be a natural thing to add, but sometimes I don't have a choice.
> 
> Seeing how I can write an entity class from scratch, which will work perfectly well with JPA, I can't see why it isn't possible to simply have NetBeans generate the same, whether there is a primary key or not. So, is there a good reason?
> 
> 
> 
>