I'd like to build a forum based on the EJB architecture. Now in the database, i have a table for each topic in the forum and this table(name of table being the topic_id) will contain information about all the articles under that topic (i.e article_id(primary key), article_title, article_body and so on).
In this light, does it mean that if my forum has 1000 topics( questions asked) den i would need to have 1000 entity beans since one entity bean represents one table?
I don't suppose so. Each table should be represented by an instance of the entity bean.Then how am i supposed to uniquely identify each entity bean and know which table it is pointing to? Can anyone give me a simple example?
Maybe you should look into your database design to see if there is a need to design in such a way that you need a table for each topic. Maybe you can have a table to keep all the topic and another table as a registry to store the register the topic with all its child topics.
Then entity bean will come into picture. you need one entity bean for each table, then if you design the database that way, you will save more effort and resources.
So are you saying that the way that i designed the database would require me to have one entity bean for each table? How is it possible to keep track of which entity bean is referring to which table then? I designed my database this way so that its more modular.
To be really honest I would suggest re-designing your database scheme. Creating database tables on the fly goes against what I have ever learnt doing db modelling. For start most real db admins will turn off a production applications ability to alter its database schema while running so the the approach will not work.
I have worked on two well known "community" java projects. A much better approach is to have a Topic table and a Article table. The Article table contains a foriegn key into the Topic Table and off you go. This would allow you to have a very !simple! Entity design of one bean for each table. EJB 2.0 does have a lot better relational mapping across db tables but still it is not perfect and will not address your issues.
If this does not work for you I would suggest using Stateless Session Beans and SQL,
I can tell you, with fairly high probability of being right, that your database schema is architected wrong. Start with a quick refresher course on OO design and you will see where the issues are.
Most likely, you will find:
a) a quick join on two tables can yield the same result as your 1000 tables (unless you are using an OO database like ObjectStore in which case "joins" are not applicable)b) performance, scalability and ease of customization are a snap with a two table design
c) there are no worries with putting so much data in two tables... a good RDBMS like Oracle or SQLServer should be able to utilize tablespaces and indexes to improve performance
Guys, I'm just confused here. What are you talking about? Tables or records? For all I know, this shouldn't be a problem with entity beans. I agree with one guy who said you can have two tables, topic and articles. Now for these, you will only have 2 entity beans with CMR fields. What are you saying you're gonna have 1000 entity beans? Instances of entity beans, right, but not 1000 different entity beans. A correction: Entity Beans doesn't represent a table, it represents a single record on a table.