I have not read this email in its entirety, but from my perusal..you are discussing a web based application interface for ASM. Currently form the new website I am able to access the ASM database. I have the ability to access it from the frontend (security restrictions so only approved users can make changes). But we have the ability if desired to create the web based interface to the ASM db w/out having people shell over, or install any sw on their PC. I am using lqm to interface with the DB through joomla. It basically just does front end queries to any SQl based db. Per my discussion with Matt it only provides "read only" data (bird queries), but it has the ability to Write to the db as well. It maintains security so only users with the proper access writes may edit the ASM DB. If this is not what you are talking about...sorry for butting in :) Wendi -----Original Message----- From: techlist-bounces@mickaboo.org [mailto:techlist-bounces@mickaboo.org] On Behalf Of AMuse Sent: Wednesday, September 03, 2008 1:04 PM To: Mal Raff; The mickaboo tech list Subject: Re: [Mickaboo Techlist] database Mal Raff wrote:
Hmmm..... just reread your note...
Are you suggesting that you could create new fields in the database that serves ASM, that would NOT be ASM-reachable... but that could be reached with a web-based MySQL interface? Bingo, spot on.
That would require permitting some of the ASM fields to be queryable by BOTH ASM and the web-based "VIM"... including the ability to correct information in those fields by either interface. That's exactly how I'd design it. Could work... although I'd be a little concerned about multiple access unless MySQL can lock fields that are in use by another user with another interface.
It's not so much of an issue as you'd think, since ASM doesn't do any locking either and we have multiple ASM users updating things at any given time. IT's "Last to the gate gets the write", but the people using ASM are generally working on different things at different times, and we CAN build in locks later if need be.
I don't know how flexible MySQL permissions are... that is can a 'volunteer' user have access to volunteer data including the required already existing ASM fields... but not to others?
Here's what my mind sees: unless MySQL's implementation has changed, it makes files in a directory. MySQL is definitely not a filesystem based DB and has not been for a number of fields -- it's a relational database very much like Oracle. So, it has "tables". The "Owner" table currently has many columns, such as "OwnerName" and "OwnerEmail". If you have a web app that needs a "OwnerPreferredTasks" field (for example) we can add the column to ASM's "Owner" table. ASM won't look for that table, not knowing about it, and
If your app isn't querying the ASM fields that we're not presenting to people, then they have no access to those fields -- unless we screw up and leave a SQL injection bug or something. thus won't be affected by its presence.
So you would add files (fields?) to that directory that would link to some (all?) of the 'people' fields already there. The 'new' stuff would be things that are specific to the volunteer database... and that ASM wouldn't even know about... and accessible ONLY through the web-based interface.
Is that possible? Is that the right way to think about it?
Part of this was to avoid having to 'hit' on you every time there was a need to change the database structure by adding (or removing) some field or other. We were worried that since ASM needs to be secure it would be easier for us to have a separate entity where if anything went wrong, ASM was not at risk.
I appreciate the not having to hit on me for changes angle; I can be tough on security issues! But for longer term use you have to ask yourself "Do we intend for this app to get lots of use?". If the answer is yes, and it contains data that is also contained within ASM, you *will* get out of sync with ASM, and down the line someone will ask me to try to tie the databases together somehow to avoid getting the data out of sync. It's much less of my time commitment to help with the design process than to try to come up with glue later on down the line, with two disparate and distinct databases.
I'm certainly open to a solution that keeps things together... but I didn't want to compromise existing operations. Chloe's involvement is primarily to manage the volunteer data. She claims she doesn't "even know what a database is". (I really don't believe that, but...)
You're getting the thrust of my arguments correct -- I apologize in advance if I'm slowing this down any and I'm not prohibiting you from having your own DB -- just trying to reach what I think would be the best long term architecture, even if it takes a bit more work in the short term. Regarding compromising existing operations, I'm quite happy to make you a copy of the ASM database, call it "asmdevel" (in fact we already have one!) and let you knock away at your hearts' content on it, without affecting the real ASM database at all. Then when the app is ready for prime time, we just tie it back into the production DB instead of the development one.
Anyway... lemme know if I've got any of this right :-)
-m-
_______________________________________________ Techlist mailing list Techlist@mickaboo.org https://mickaboo.org/cgi-bin/mailman/listinfo/techlist