From th.j.v.hoesel at gmail.com Tue Aug 11 23:36:09 2015 From: th.j.v.hoesel at gmail.com (Th. J. van Hoesel) Date: Tue, 11 Aug 2015 22:36:09 +0100 Subject: [Act-dev] Act-Voyager Database Transformation Message-ID: There is some design issue I have and like some feedback from those who concern... but first of all, If you have missed it, there was some form of a web-application during YAPC::NA a month ago, we got it working although it didn't much. But what it did, was useful and I hope to have a much better version for YAPC::EU... it showed the upcoming events. Ever since I started working on Act, I felt that we should redo the database design... And I am thinking of a sort-of Entity-Attribute-Value design, to allow for future extensions of the logical datamodel or easy creating of new plugins and adding features, without changing the underlying real datamodel. A good example of where it would be useful is the list off all those 'social' ID's we have, CPAN, FaceBook, Twitter, we can't keep adding columns. Another example... we have a cross-table that binds attendees to the talks he/she visited. If we could use an EAV model, we could now simply add a 'rating' attribute and build a plugin or extension that would make it very easy to quickly give 1 to 5 star review straight after attending the talk The other thing that bothers me is the fact that we have to cater for a multi lingual audience and should have multiple entries in the database for each language... currently, we only do it for user profiles (bio's) and for news articles. And where applicable, we have to store it in the INI files in an awefulway. Anyways... The way I deal with it currently, is that ActNext has a data-store that provides Items and Sets and those are different from the underlying DataBase Schema (and always will be - even when changing to an EAV). However, now I am doing this for the legacy database.... and later, it need to be redone for the new model (without breaking the API)... I have been advised more than once to just migrate over and start from scratch with a new database design. But this leads to a different problem... Will we now have two databases that need to be synchronised bidirectional, or is merging legacy with ActNext on a scheduled basis sufficient. Some ideas about database transformation are very welcome. Theo