I'm building a site that contains "panels" which are used as containers for various information. I have set it up so panels are editable, which is simple for panels that just contain text. For that I just grab the content from the database and wrap it in a textarea rather than a <p> tag. For panels that contain table views however this is proving to be a more difficult task.
First off I'm having trouble allowing the admin of the site pick what information is in a given table (for example if the admin wanted to add a panel view that showed each members first name, last name, and picture they could pick from those columns in my database). I've come up with a few ways to do this, but each have their own set of problems.
I tried using the INFORMATION_SCHEMA table to generate a table containing the possible tables and columns that the user can choose from. But when it comes to building the query with PDO I have problems. For instance with prepared statements you can't use a variable for the schema.
I also thought of using MySQL views but I can't seem to figure out how to do it that way either.
My second problem is allowing the admin to add rows to the tables directly. Right now all the add row template does is create a row with a text field in each column. This is good for purely text options (like first name) but for things like pictures obviously a text field won't work. Should I create a table that contains this metadata or perform the check in PHP? If it's the latter, how would I know what input type the column needs?
I think my main problem is I'm trying to solve too many things with only one design change (or not focusing on one problem at a time). It's resulting in me becoming very flustered and confused. Help is greatly appreciated and if you need anymore information like how my database tables are currently setup I'll provide an ERD.
Edit: I just wanted to make it clear that I don't want to allow the user to actually manipulate the tables in the database, but rather select what information from the existing tables is shown on a given panel.
Coding the ability for users to freely query a database has a lot of problems (including security) and is way more complicated than predefined information queries that simply return a defined set of information.
It also places the burden of defining which info might be useful onto the user. It places the burden of deciding whether a certain information should be accessible to a particular user onto the query logic and database access rules.
Effectively you are trying to copy PHPMyAdmin with a different design and only your defined database as a target.
Related
I am working on a form for storing information about the themes of the queries we receive in our company.
I am using php/MySQL to store radio button data such as:
Name of employee
Medium of query (e-mail/phone/in person)
With radio button data such as this, I can easily use PHP to query the database and e.g. count the numbers of queries answered by e-mail by each employee.
The trouble I am having is with data regarding the theme of the query. This is checkbox data with a lot of different checkboxes (50+). We would like to be able to add or remove checkboxes from time to time, though not very often.
I used to store this data just as comma-separated values in a single cell in the database and then export to excel to work with the data, but now I'd like to use another PHP form to generate statistics on the themes.
My research has lead me two to ways of doing this, that may be possible:
Creating a separate table in my database for my themes with one column for each possible theme, so that I'd have as many columns in my database as the number of checkboxes in my form.
Use the php functions serialize to store the checkbox data in one cell in my database and then later using unserialize to work with the data in php.
I am an absolute beginner, so with both options I'm unsure how I'd actually implement it:
With this option I am unsure whether my MySQL columns should just be "theme 1", "theme 2", etc., or whether they should have the names of my checkbox values, e.g. "money", "personal problems", "practical issues", etc. I have not been able to find a good resource on how to store the checkbox data in the right way, when the user may sometimes have clicked just 1 theme, and in other instances may have clicked 10 themes.
With this option I am unsure how I could populate a dropdown with unique values, and how I could later count instances of a unique value across the rows in my database.
Any help you can give me on this, including links to tutorials or questions similar to this on stackoverflow, would be much appreciated. I haven't been able to find anything about this that I could understand, other than I am thinking option 1 is probably the right way to go.
EDIT: After having received an idea about how to do this from David, I am updating my post with my attempt to understand how I would go about this.
What you're describing can be thought of as a many-to-many relationship. You have:
A form record, which can relate to many themes
A theme, which can relate to many form records
In a situation like this, the relationship itself is a database record. Consider this table structure:
FormRecords
----------
ID
SomeTitle
UserIDWhoFilledOutForm
etc.
Themes
----------
ID
ThemeName
etc.
FormRecordThemes
----------
FormRecordID
ThemeID
Each "primary entity" has an identifier and information about that entity. Then there's a "linking table" which has information about the relationship between those two entities.
Any time you present a form, you simply select from the Themes to populate the check boxes. You can add new ones as you see fit. You probably shouldn't remove any, though you can "soft delete" them by setting some flag on the record to indicate not to display them on the form.
If you ever want to edit the Themes in any significant way (a way which would somehow invalidate previous uses of that record, such as completely changing its name/title), then keep in mind that you'd be modifying the entire history of its use. I don't know if this is a risk in your domain, but in cases like that it might help to de-normalize a little bit by storing "Theme at that time" values in the relationship table. Like, the name of the Theme at the time that relationship was created. It's best to avoid this scenario entirely if possible, mostly by making key Theme values immutable in the domain.
Don't store delimited lists, don't store serialized data (unless the entire object really is a single data point)... Keep values separated into their own actual values in the database. Relational databases are really good at querying relational data.
You can put all values of checkboxes got from user into one CSV format string and store in one cell. Later on you can just split the string and get the values back.
Please I am creating a database system for a group,using mysql and php.I am faced with some challenges,these are
1.I want to make the database system dynamic - thus where an administrator using the system would be able to add columns to a specific table from the front end without having to know something about mysql and php.
2.Also,I want the administrator who is ignorant of mysql and php, to be able to add tables to the database through the front end (PHP page).
3.With the aforementioned problems in (1 and 2), how would I make the columns added by the administrator appear on a form (php page) from the database, and how do I check for errors on the form.
Please these are instances to clarify what I have said.
a.What should I do to make a client add columns to an existing table in the database without any assistance from the technical team?
b.What should I do to make a client add tables to an existing database without help from technical team?
c.How do I output columns added by an administrator to a form and also check for errors on the form (php page) .
Any help is welcomed.Thank You
Well basically you can just write queries like ALTER TABLE xxx ADD column VARCHAR(100) etc. filling in the desired values from a form. This is, however, strongly discouraged. Not only would this mean your script would be able to execute queries which normally can only be executed by (mysql) users with administrator rights, it is also very susceptible to security problems.
Reading your question immediately starts me to think of an EAV-like1 database system, although it is a highly controversial scheme to use in a relational database system like mysql, to use on any system actually...
A few problems that come to mind (most points apply to EAV too btw)
You will lose any logical structure
As any type of data can be linked to any type of entity, so - in your database at least - there is no logical relation between your attributes (or columns in your case) and your entities (tables in your case), other then just being present.
Very, very hard to maintain
If your tables grow, what columns should be indexed? How would you prevent from someone ignorant - and as you say they are by default - adding 200 columns to a table? Numerous other problems can be summed up here...
What about restrictions?
How are you gonna decide who is allowed to add/delete/edit what columns? And how are you force them to choose the right column-type? Or when a table is added: what should be the (coumpound) primary key? Remember: your administrators are ignorant. I guess this would rise the need for meta-tables, holding this kind of information. Are you sure you want to write all the logic for this? And are you sure you are wanting to keep track of bugs etc, bugs which will most probably allow your system to collapse like a card-house?
It smells like an excel sheet...
Without functions that is, but still. So why not send your administrators a link to google docs? ;)
No really, it sounds like a very bad idea...
Please post your full user-case, I'm quite sure we can think of a better solution then adding columns and adding tables to a database.
I am trying to find the best way to create a search engine for my website. All of the items that need to be searched are in the mysqli database, but I also have tables in the database that need to be excluded from the search (ie. Users information, navigation menu tables, etc). The only solution that I have come up with so far is to search each table individually for that key word and then display the results.
Is there an easier way to do this? I would like to have a ‘table group’ or something like that so my query could be something like:
SELECT * FROM table_group WHERE any_column LIKE “%search_string%”
The database has around 30 tables right now, but tables can be dynamically added and this will grow as the site is used more. What is the best way to go about this?
If you want to pursuit the idea of creating a search engine querying to the database, I think you have to query for the metadata of the database: the list of tables and the list of fields each table has.
However, this is difficult to follow because at the end you have to present the information to the user in a printable view: it isn't the same finding a proper name (and hence you have to present the page userInfo.php -to say an example- to the user) or a name of the company (and therefore you have to present a totally different page.
I think at least you have to create search elements based on the pages you have in the application. This means that you have to create a table with the information for the search engine: how to present this information, in what tables/fields should it search, etc.
Even if there will be tricks. What if the user searchs for "smyth"?? Have the search engine be smart enough to return "smith"?? And if you have two fields, one with the name and other wit the surname, what will happen the user types "john smith"??
I am building an PHP/MySQL app and I am allowing users to create their own custom (as much as they want) profile data (i.e. they can add any amount of info to their profile with additional textboxes, but there is a "CORE" set of user profile fields)
For example, they can create a new textbox on the form and call it "my pet" and/or "my favorite color". We need to store this data in a database and cannot obviously create columns for each of their choices since we don't know what their additional info is before hand.
One way we think that we could store all "addidional info" they provide is to store their additional info as JSON and store it in a MySQL text field ( I love MySQL :) )
I've seen Wordpress form builder plugins where you can create your own fields so I'm thinking they must store the data in MySQL somehow as NoSQL solutions are beyond the scope of these plugins.
I would love to stick with MySQL but do you guys think NoSQL solutions like MongoDB/Redis would be a better fix since for this?
Thanks
One way to approach this is to use a single table using the EAV paradigm, or Entity-Attribute-Value. See the Wikipedia article. That would be far tidier in most respects than letting users choose a database schema.
You could create a table of key value pairs where anything not in core would be stored. The table would look like: user_id, name_of_user_specified_field, user_specified_value;
Any name_of_user_specified_field that starts showing up a lot you could then add to the core table. This is referred to as Entity-Attribute-Value. Please note, some people consider this an anti-pattern.
If you do this, please add controls to limit the number of new entries a user can create or you might find someone stuffing your db with lots of fields :)
MySQL can handle this just fine. If the additional data is always going to be pulled out all together (i.e. you will never need to get just the pet field without any other additional fields) then you can store it serialized in a column on the users table. However, if you want a more relational model, you can store the extra data in a separate table linked by the user ID. The additional table would have a column for the user ID, additional field name additional field value, and whatever else you might want with it. Then you just run a JOIN query when getting the profile to get all of the extra fields.
We're making the plans now, so before I start progress I want to make sure I'm handing things in the best way.
We have a products table to which we're adding a new field called 'format', which is going to be the structure of the product (bag, box, etc). There is no set values for this, users can enter whatever they like into that field, however we want to show a drop down list of all formats that the user has already entered.
There's two ways I can think of to do that: either a basic SELECT DISTINCT on the products table to get all formats the user already filled in; or a separate table that stores the formats and is linked to by the product.
Instinctively I'd like to use SELECT DISTINCT, since it would make my life easier. However, assuming a table of a billion products, which would be the best way to go?
I think i would opt for the second option (additional table + foreign key if you want to add constraint), just because of the volume and because you can have management that will merge similar product form for example.
If you decide to keep everything in one table, then build an index on the column. This should speed the processing for creating the list in the user application.
I'm somewhat agnostic about which is the best approach. Often, when designing user interfaces, you want to try out different things. Having to make database changes impedes the creative process of building the application.
On the other hand, generally when users pick things from a drop down box in the application, these "things" are excellent examples of "entities" -- and that is what tables are intended to store.
In the end, I would say do what is most convenient while developing the application. As you get closer to finalizing it, consider whether it would be better to store these things in a separate table. One of the big questions is whether you want to know all formats that have every been used, even if no user currently has them defined.
Since you are letting users enter whatever they want I would go with the 2nd option.
Create a new table and insert in there all the new 'formats' and link to the product table.
Be sure when you create the code to add the format the user typed in, check if there is an equal value on the database so you won't need to distinct them as well.
Also, keep it consistent, either by having only the first letter upprcase of each word.