-1

Would it be possible to create a similar entity based on another one? For example, what if I'd like to have user specific tables that are based on one entity. Without any ORM I would just create the same table with a different prefix and do the queries on the table with the specific prefix.

Not sure how to tackle the problem with Symfony 2.5 and Doctrine and I just can't find a concrete example anywhere around, but seems like the solution might be around the Doctrine Event Manager and the Load ClassMetadata event. I just can't make sense out of the documentation.

MinusFour
  • 13,913
  • 3
  • 30
  • 39
  • why without ORM? With doctrine SuperClasss you can archive this – M. Foti Sep 14 '14 at 08:09
  • I never said I want to do it without ORM. I just gave an example of how I would solve the problem without ORM and I'm looking for the way to do it with ORM. I found a way to change the table name mapping but it seems it doesn't force the schema to update nor does it persist the objects. Also, it might not be possible according to this post: [link](https://groups.google.com/d/msg/doctrine-user/ovYk79e78E0/pjBSViMY50wJ) – MinusFour Sep 14 '14 at 14:00

1 Answers1

0

Without exactly knowing how your schema looks or what you're trying to achieve, it's hard to give a precise answer. But let's try:

If you have two entities which share a common set of properties, but differ in others, you basically do the typical OOP inheritance thing, you create an abstract parent class with the common stuff, and two children with their specific properties.

In Doctrine, there are different inheritance strageties. Read about them at http://doctrine-orm.readthedocs.org/en/latest/reference/inheritance-mapping.html

Each of them has their pros and cons. Basically, you can select if you want everything to be in one or in two tables. Set up a test case and check what works better for you.

Note: The class properties in an abstract superclass (no matter which strategy) must always be private.

Community
  • 1
  • 1
lxg
  • 12,375
  • 12
  • 51
  • 73
  • I don't really have an schema built up at the moment. But here's what I'm thinking: Let say you have an event table where you log all events of each user. The more users you have, more events get registered on the table and it can get pretty big. So what I'm thinking is to create event tables for each user that registers. I would then have user1_events, user2_events, user3_events and so on. I would like having one entity "events" and create dynamically the other entities with their correspondent prefix. – MinusFour Sep 14 '14 at 20:03
  • Sorry, but that sounds like a bad idea to me. And with Doctrine2, this will definitely not work, because you would have to add entities dynamically, which will not work (at least not without most ugly hacks). But I wouldn't mind those large tables. MySQL (and other RDBMS) can handle millions of rows without problems. It's just a matter of proper indexing. – lxg Sep 14 '14 at 20:15
  • I kind of think that it is a bad idea too. I'm a little bit worried that my table will grow too much to the point of being unmanageable, although I'm not sure how much it affects my queries performance. I've never really worked around with tables with millions of registers. – MinusFour Sep 14 '14 at 21:22
  • Huge tables can of course cause problems. But if your schema is slim, and you've created good indices, you shouldn't worry. For example, if you have an *Event* entity, categorize the event types, assign numbers to them, and only store the number. (Just saying, because I've seen people storing category IDs as strings.) – lxg Sep 14 '14 at 21:25