Data in on one side, API to expose data on other side -> 2 different projects with their own ORM layer?

This isn't a class开发者_C百科ic programming language question, but it's keeping me busy so I figure I might as well tap in to the experience of Stack :-)

I have a system that accepts measurement data from various sources. These data messages are put on a queue. Now I need to build:

1. A system to regularly read messages of that queue and persist the data within them to a database (probably a PHP script that is invoked by cron)
2. A system to expose that data to external parties (implemented as an API/webservice)

However, the database scheme is bound to change, so I figure I'd try my hands at Doctrine to abstract that part.

Now, if I use two projects, I'll have to use Doctrine in both, with them both having objects that reflect the same tables in the database below. So if the db changes, I need to change the model of two projects. That feels wrong.

I can use one project, with one ORM, so that if there are changes I only have to change one layer. However, then I have both a script using that model, and a webservice, all in the same 'project'.

Thinking litteraly 'projects', as in Netbeans for example. I suppose I would make a 'model' folder with the Doctrine objects, a 'script' folder which is accessed by cron and an 'api' folder which is accessed by the webserver.

It feels weird that one project has different applications, but it also feels best to have only one ORM layer. What's the decent thing to do?

---

I think you're just thinking about it the wrong way when you think about it as two separate "projects", although I see where you're coming from. Your project is to import sensor data and provide an interface to receive that data, so it makes sense to have them under one "project".

As to the schema changing and using an ORM, I'd suggest checking out MongoDB (or another NoSQL DB, I'm biased towards Mongo because that's what I know). You'll still probably want to use something like Doctrine but because it's inherently "schema-less" you can be a bit more flexible with what you put into it. I suggest still using Doctrine because that can be a liability as well as an asset if you don't manage it well (ie, insert a date into an integer field and Mongo won't care...)