I'm not entirely sure that this is the Exchange site to post this on, but I haven't seen another that fits.
I am looking for a project which provides scaffolding that supports granular restrictions. I don't need custom labels or anything pretty like that. I have team members who are intelligent enough to add/edit rows in a table, but I cannot let them have access to all tables, or to delete in every table, etc.
What I'm looking for is something like phpMyAdmin, but with the ability to turn off tables, turn off columns in some tables, make some columns read-only, etc. All per user. This would allow me to provide raw db access to different members of my team, without allowing full omnipresent access.
Is there a project which looks to provide this?
Preferably in PHP & mysql.
Thanks
Take a look at Adminer and Adminer Editor.
They are highly customizable in PHP and they have the additional advantage of being contained in a single PHP file.
If you just want to hide/write-protect some tables and columns, you can always do that in MySQL itself.
Related
I need to create an application with an editable database structure. Where you can add/delete/modify tables and fields, views and structure of the database. All in production and real time.
The purpose is that the application can be adapted to the needs of the company. Allowing you to store the information that is needed, where it is needed.
I use laravel 5 and MySQL, but my question is not about my software. My questions are:
Is there a methodology, or a set of steps to follow, to achieve this functionality?
And if it exists, is there any package to apply it to laravel?
Entity-attribute-value model allows to have a DB with something like a "dynamic schema" and be able to run indexed queries on its tables (though "tables" become different from what you would have if you used the normal approach). With it you can add and remove fields and have the values indexed (unlike in a document-oriented NoSQL DB). Downsides: a lot of joins, performance might suffer; however, I've seen pretty large systems get away with it. Don't know if and how it can be applied in Laravel context, but googling gives at least some results.
You need to use Business Intelligence and reporting tools, which fulfil all your needs. They run with any db, no matter which fields you add or remove they will adjust themselves. One of the best example is:-
https://github.com/getredash/redash
[Edit: I have awarded the bounty but not the question, as I feel there is still a chance for a better answer.]
I usually code my MySQL data entry interfaces in php.
But for quick projects where I would like to focus on the web side of things (pulling data from the database), I am looking for a form front-end to MySQL. Ideally, this would be an off-the-shelf Win or OSX program that I can hand over to a friend or client so she can input data into forms.
An Example
The lines above summarize the question, but here is a typical situation to showcase why "just give them phpMyAdmin" or some other web interface to MySQL generally wont work.
We have two main tables: images and albums. The third is an associative table that associates images with albums.
Images: id (PK), filename
Albums: id (PK), album
Album_Image: id (PK), imageid, albumid (these are foreign keys: the two id PKs from the Images and Albums tables)
For big projects, I don't mind coding a nice "back-end" interface (CRUD) that lets me edit data in a very comfortable, customized way.
For small projects, for instance an image gallery for a friend, I would like to be able to only program the "front-end": web interfaces that pull data from the database.
For the back-end, ideally, I would like to give my friend an off-the-shelf solution so she can enter images, albums, and associations between images and albums.
In the old days (I am thinking of DBaseIII), it was really easy to give interfaces to do that entry side of things.
Here is a crude approach I have tried. I have set up a view of the associative table joined to the parent tables, so it shows albumid, imageid (the PKs) and album, filename (associated fields in the parents) using this query:
SELECT albumid, imageid, album, filename FROM album_image axi
JOIN albums a ON a.`id` = axi.`albumid`
JOIN images i ON i.`id` = axi.`imageid`
The idea with this crude approach is that my friend would enter the parent PKs (albumid and imageid) in the associative table through the view, and that after hitting Insert, the full parent fields (filename and album) would be visible in the View for visual feedback. I have tried this view in three GUI tools: SQLyog (Win), HeidiSQL (Win) and Sequel Pro (OSX).
In Heidi and Sequel Pro, I have not found a way to edit the view.
In SQLyog, I can edit the PK fields (albumid and imageid) in the view, and the parent fields (album and filename) show properly when I hit "refresh". That's great. It works because even though the view shows three tables, we are only editing from one table. But I cannot delete a row as SQLyog doesn't know from which of the three tables we are trying to delete. On the other hand, in SQLyog, I able both able to insert and delete in a Query tab that contains the same query that creates the view, because in this kind of tab SQLyog allows me select the table being edited. So that works, but this workflow might start to be a little complex for my friend: she would have to open SQLyog, connect, open a saved query, select the right table to edit within the query, and make all the other right moves.
Wondering if any one knows an existing tool that is really good at making forms for MySQL---ideally a Windows or OSX binary. I will consider a web solution, but I am not interested in a framework---the key is speed of deployment, and if we went the framework route I would be better off making the interface with my own CRUD libraries. Again, I can code it, but my goal with these kinds of "quickie projects" is to focus my workload on the front end (web interface to the database), leaving the back end to an off-the-shelf tool.
Thanks heaps in advance for any insights. :)
Edit: I see that no one has mentioned Navicat or MySQL Workbench. I haven't tried either, wondering if someone knows off the top of their head whether they would do the trick.
I think what you're looking for is a form front-end for MySQL.
Since it sounds like you are more interested in binaries than web apps, have you looked into Microsoft Access? It can talk to MySQL and could be just what you need.
Open Office Base may not have quite the features you're looking for.
You already have the solution, your attempt at making things simpler is creating the complication.
There is no benefit to your friend in adding album images in a view if that view that only shows the filename and album title after they have entered the IDs and clicked Insert.
Before adding an image, your friend needs to know the album ID and the image ID. This information may not be in the view. She will therefore look at the album table and look at the image table to find this information, cross-referencing the filename with her own list of uploaded images.
Then, having written these two numbers down, she can insert a row directly into the album_image.
For visual feedback, she can check the frontend website.
It is true that a view showing the album name and filename would make deleting entries easier, but I would assume that images and albums are added much more frequently than they are deleted.
The ability to edit an associative table in a view that shows linked information, therefore, should not greatly affect your choice of tool. I could suggest tools, and phpMyAdmin is a logical choice, particularly if it is desirable to teach your friend computer skills that are widely applicable. It appears you have already identified some executable tools.
I imagine that you could add some additional hidden frontend views that could make your friend's workflow easier, such as a list of images and IDs that aren't in albums, a list of album IDs, or a view that shows the IDs. I do recommend you consider extending the frontend with a simple login and Edit options using your CRUD library, rather than devising a separate backend GUI.
I appreciate this is not an answer to the exact question, but it does resolve your problem.
I'm not sure if this will be helpful or not. I was hoping to find a UI with some eye candy/styling, but while searching I stumbled upon this:
https://blogs.oracle.com/MySqlOnWindows/entry/introducing_mysql_for_excel
As part of the new product initiatives of the MySQL on Windows group we released a tool that makes the task of getting data in and out of a MySQL Database very friendly and intuitive, and we paired it with one of the preferred applications for data analysis and manipulation in Windows platforms, MS Excel.
Like I said, not sure if it will help. I'm in a similar situation - low-tech, low budget client. The difference is my weakness in MySQL, but for me I just need a single table, so I think this will work.
There is no tool that will allow you delete such values from such a view, not for mysql, since For a multiple-table updatable view ... DELETE is not supported, see Updatable and Insertable Views
I guess you are looking for the equivelent of the Python based Django admin system which practically builds itself from analysis of the data structure.
Frameworks like Symfony, Cake and Yii have some of this built in, however I'm guessing that your database architecture may not be compatable as these types of systems normally require you to stick to strict naming conventions, but it's certainly worth taking a look.
Playful,
I already posted one answer, but this one is different enough to merit a seperate response, IMO.
Since you are looking for a simple, client-friendly solution, may I suggest Adminer?
http://www.adminer.org/en/?
Specifically, I used the Wordpress plugin here on a site recently:
http://wordpress.org/extend/plugins/adminer/
It provides pretty much full phpMyAdmin funcitonality. Very easy for the client, and if they want to, they can export the database as .csv and edit in excel, then re-upload. Just about everyone is familiar with editing in Excel, and they can make backups regularly.
Hope this helps!
J
You can very quickly and easily make a front-end for this type of use with Xataface. I find it very quick and useful. I would be happy to help you get going with it.
www.xataface.com
I have a design discussion with a collegue.
We are implementing a PHP MySQL database application. In the first instance we have written the Insert Get Update Delete, SelectAll and Search functions for a particular table, writting the table and fieldnames in the code, with several php files, one for the object class, one to draw the HTML table for that table, one for editing a row of that table, one containing the above functions, etc.
The disagreement comes as I have now written generic functions that read/write from the database and draw the HTML taking the table name as a parameter, letting these functions discovers the fieldnames from the database or class. So now that code can be used for any table, with any fields without having to manually go in change each function that needs alteration. I understand there will be cases where more table specific functionality is needed, and this I think that should be done as requirements arise, integrating common parts where possible.
My collegue on the other hand is adamant we should keep a set of files separate for each table, i.e. around 5 php files for each table. The read/write functions written differently in each case, with the need for any changes required for all tables to be affecting 5 x number of tables amount of times.
I can certainly say there will be more than main 15 tables in the database that will at least need basic funcionality.
What approach do you think is most appropriate?
One of the important principles in programming is DRY : Don't Repeat Yourself. So, everything common to several usecases should be written once, in a single location.
Now, I've never had to develop an application where each database table had the same, generic, crud pages. If it were the case, it wouldn't be a functional application, but a database management application. Are you sure you aren't redeveloping phpMyAdmin?
If you need the same code to handle several base operations on several tables, I would say you shouldn't write that code more than once : no need to repeat yourself :
it would take more time writing the application
it would take more time (and possible cause more bugs) when maintaining it
A possible solution could be to put as much common code as possible into a single class, common to many tables ; and, then, have a specific class for each table, that would extend that common class.
This way :
The common code would be written only once
Each table could have its specific code
The common code could be overridden for a specific table, if necessary.
About that, see the Object Inheritance section of the manual.
About that common class idea, you could even go farther, and write pretty much no code at all, if your CRUD is generic enough : there are ORM frameworks that might do that for you.
For instance, you might want to take a look at Doctrine.
We're on the first stages of development, and we don't have the complete functional specifications for the web application we're developing. Yes, we know, but it's not our fault.
So, we're building some parts keeping them pretty simple and straight-forward so we can build on top of that when we have more details on what to build.
We have a section for clients, for ads, for users, ... and I wanted to keep things separate because we don't know what's coming in the future. Yes, at the moment we have only a few fields and some basic listings and editing pages, but all that will grow.
It's not that I don't want to implement some generic code that we can reuse. It's that we don't know yet what will be the limitations in the near future, and I don't want to write generic code that we'll have to parametrize intensely.
For example, Alex built a generic Update method to which you pass an object and it will create an UPDATE SQL statement and execute it. OK, that's cool, but that doesn't work for the Users section of the web app because we store the password encoded. First, it won't encode the password. Second, if you edit a user and don't enter anything on the password and password-confirmation fields, the old password will remain. So, we have a problem with the generic Update method, and as I see it there are two possible solutions:
a) Parametrize the Update method so if it is modifying a user, keep the password if the password on the object is blank. And encode the password, of course.
b) Override the Update method for the child class.
Alex's implementation didn't use inheritance and he used the generic methods in a static class he'd call this way DataAccess::Update($object);. The method takes the table name from the class name as he modified the database to make them match (I prefer "Clients" for the table and "Client" for the class). So, option b is not possible with Alex's implementation.
The way I was trying to build it was keeping separate Update methods for each table. Yes, I was repeating myself but, as I said before, we don't have a full specification, so we don't know how it's going to grow. We have an idea, but we don't have the exact details.
So, the point here is that I don't want to write generic code until we have a much more detailed specification so we can evaluate what can and what cannot be shared between the parts.
Not all sections of the web app work the same and, as JB Nizet said: "If it were the case, it wouldn't be a functional application, but a database management application."
And I can tell you for sure this is not a database management application, even though Alex would say "we're just building a database app." Well, maybe, but a database application is not only showing/modifying the tables. And now, views won't solve all problems.
Again, as JB Nizet said: "If it were the case, it wouldn't be a functional application, but a database management application."
And now I'm repeating myself again, but this time there's no reason for that.
Thanks for your time.
I'm building an application (using the zend framework) where we will have multiple clients who login and use the application, and each of these clients will be storing lots of data about their users (I'm using MySQL btw).
Basically I'm wondering 2 things:
Is having multiple databases, one for each client (ie. ipd_client_CLIENTNAME) with identical tables a stupid idea? Or will it actually be more responsive (than putting everything in one database) if we have 50 clients with 20,000 users' data in 'their' database?
I've already managed to build the same system but all on one database, my model classes simply grab the name of the client logged in (in the model classes' init() method) and then dynamically change the name of the table they grab data from, is this going to be just fine?
If the "every client on the system gets their own database" makes sense, how exactly would I dynamically change what database my db models connect to (based on which client is logged in)?
In case this made no sense, here's an example of what the databases would look like in the two different scenarios (given 2 clients registered on the system):
Multiple Databases:
ClientA has a database called "ipd_clients_ClientA" with tables "users", "lists".
ClientB has a database called "ipd_clients_ClientB" with tables "users","lists".
Single Database:
ClientA has tables called "users_ClientA", "lists_ClientA".
ClientB has tables called "users_ClientB", "lists_ClientB".
Hopefully that makes sense.
Any help would be GREATLY appreciated, thanks!
i would use Solution 2, with multiple Tables for your clients in combination mit MySQL Master / Slave Replication.
MySQL Master Slave
If you want to use different Databases, you can use native functions of Zend Framework:
Tutorial multipe dbs
And than select the one for the client by some kind of prefix.
Although you accepted that answer, I beg to differ. I think having multiple database would be much easier to manage.
The way that tutorial uses multiple databases is far more complicated than it needs to be. The way I do it is by simply defining the client name in a root file (index.php?) and then my bootstrap uses this constant to load in the correct ini file.
If you start with the separation, you can then go on to using the same principles for caching data in separate structures far more easily.
Using separate databases would make it much easier to manage individual clients.
While ZF does have support for multiple database connections, I would not use them in this particular case.
It makes more sense to me to store a client_id (or site_id) in each of your data tables and use that to filter. Duplication makes it very hard to make application-wide changes. Whenever I see dynamically named tables like that, I usually think it's poor design.
For caching, just prefix any cache keys with the client identifier.
I'm writing an application that that I'm going to provide as a service and also as a standalone application.
It's written in Zend Framework and uses MySQL.
When providing it as a service I want users to register on my site and have subdomains like customer1.mysite.com, customer2.mysite.com.
I want to have everything in one database, not creating new database for each user.
But now I wonder how to do it better.
I came up with two solutions:
1. Have user id in each table and just add it to WHERE clause on each database request.
2. Recreate tables with unique prefix like 'customer1_tablename', 'customer2_tablename'.
Which approach is better? Pros and cons?
Is there another way to separate users on the same database?
Leonti
I would stick to keeping all the tables together, otherwise there's barely any point to using a single database. It also means that you could feasibly allow some sort of cross-site interaction down the track. Just make sure you put indexes on the differentiating field (customer_number or whatever), and you should be ok.
If the tables are getting really large and slow, look at table partitioning.
It depends on what you intend to do with the data. If the clients don't share data, segmenting by customer might be better; also, you may get better performance.
On the other hand, having many tables with an identical structure can be a nightmare when you want to alter the structure.
I'd recommend using separate databases for each user. This makes your application easier to code for, and makes MySQL maintenance (migration of single account, account removal and so on.)
The only exception to this rule would be if you need to access data across accounts or share data.
This is called a multi-tenant application and lots of people run them; see
multi tenant tag
For some other peoples' questions