What, if any, is the difference between MySQL views and the way that phpMyAdmin shows its tables? When I created a view on phpMyAdmin by clicking "Create view" under "Query results operations" under "Browse" in a table:
,
the created view looked exactly like the view shown in the "Browse" window for that table:
I am more talking about visual style here, I know that since I used the defaults the table includes the same columns/rows. Do all SQL views look the same, visually, as phpMyAdmin tables as shown in the GUI? Is that some sort of standard, or just the way phpMyAdmin does it, and others could be different?
Is it possible to create views in the browser, or are they just created on the server for the convenience of the developer? W3schools doesn't have a syntax-testing tool for views, which makes me wonder, as they have one for pretty much everything else.
I am using phpMyAdmin 4.1.5.
You are asking about visual style. Neither tables nor views have a particular style. The tool you use -- the command line, PHPMySQLAdmin, MySQL Workbench, or whatever -- can display them however the developer likes.
For convenience, views and tables will likely look very similar or the same in most tools, because they have similar structures (but not the same functions or purposes). But how they look is up to the developer of the tool.
If you do not do anything else, a view of a table will be the same as the table itself. You might create a view of an employee table called phonebook that had only name, office number and phone extension. The employee table might only be readable by the HR director while the phonebook view would be accessible to the entire company. In this case the view has fewer columns than the underlying table.
Or you could join the employee record with the department record that he is assigned to and create a view with more columns than are in the underlying "employee" table. It sounds like you just took some default options and created a view that was just like the underlying table. It is ok for a start, but now drop the view that you made and recreate it with some purpose in mind and you will see the differences when you browse it in phpmyadmin.
Related
I have years of Access programming under my belt, with either Access or SQL back ends. I'm volunteering my time to help a small nonprofit build a volunteer database. We are forced to use SharePoint Lists as the data backend.
Our first migration using the Access wizard worked but messed up the data because I had not created all the required relationships prior to upsizing. I did my homework, and we tried again. But even though we created a folder for all those files, the Access wizard put the lists at the root of the SharePoint file, and now they are mixed with the first round of tables, as well as other folk's stuff. So, my questions are:
Can we specify where those SharePoint Lists are stored beyond the root directory? (I worry that others may inadvertently edit those lists...)
How do I delete the lists? It says we cannot because relationships are set
How do I in the future alter the lists (like altering tables in SQL?) I know I'll need to add columns eventually.
I've searched MS and here, and MS solutions are crazy simplified, so they don't answer my questions. TIA!
Can we specify where those SharePoint Lists are stored beyond the root directory? (I worry that others may inadvertently edit those lists...)
Yes, go to the SharePoint site. From ONLY the Team site, create a sub site.
(regular sites don't work - MUST BE A CHILD of TeamSite).
You can up-size the access tables to that site.
So, just like creating a folder, or in this case a site?
Say you create a new teamsite (MUST be subsite - so crete a subsite to teamsite) called Customers. Then you can specify that target for the database. As noted, since the access table features are "special", only sites created as sub sites to TeamSite(s) will work.
So, it stands to reason that each database should get its own site (perhaps better term is sub-site). Then you can up-load/up-size a database to that one team site you just created - and all tables are thus "grouped" or part of that "one" site or URL.
So say we have a database called customers - then we create a (sub) site called customers. Your url would thus be "something" like this:
https://myCompanyName.sharepoint.com/TeamSite/Customers
How do I delete the lists? It says we cannot because relationships
Well, actually, even in Access regular tables - you as a general rule can't delete a table that is part of a related set of tables. This suggests then you have to delete the relationships first.
Display the site contents,
right click on the child table that has the related column
(choose settings).
You now are in the "settings" for that one table/list.
You can click on the column that has the relationship.
You see this:
So, you can remove the relationship. (scroll down to bottom).
And if those tables are LINKED from access?
You can use the table view in Access - and change/add columns - you do NOT necessary have to do this from the web interface.
How do I in the future alter the lists (like altering tables in SQL?) I know I'll need to add columns eventually.
You can do this from Access or SharePoint - Access side is better choice.
if the table is linked from Access, then use the table view. You not be able to jump into table design mode - but if you open a table, you see this:
And while in above I am on the last (add new) column, if I wanted to say change or add a index to say FirstName column? I could do this on SharePoint, but you ALSO can just click on any column - note the ribbon now:
So, all this is quite much basic SharePoint stuff.
But, open the linked list - you can add new columns, or remove columns - the above ribbon options show the options you have (such as index, etc.). And like always, to delete a column, in that table view from Access, right click - you have this option:
So, you add, or delete fields BOTH from the SharePoint site, or from the above table view in Access.
MySQL Documentation explains how to create a view. However it doesn't explain why should I make a MySQL View in the first place.
Thus, my question is, what is MySQL View? What is it for? At what circumstances should I make or not make one?
Quoting the documentation
The view definition is “frozen” at creation time and is not affected by subsequent changes to the definitions of the underlying tables.
I don't see how creating a view would be beneficial, so please, enlighten me.
View the data without storing the data into the object.
Restrict the view of a table i.e. can hide some of columns in the tables.
Join two or more tables and show it as one object to user.
Restrict the access of a table so that nobody can insert the rows into the table.
Where I work, we use the views as big painful querys that we need many times, we decided to create views for them instead of doing a manual query and when we need to access the information
SELECT * FROM view WHERE (anything)
Right now I have a database in phpMyAdmin, and off the the side of the screen, it shows the database name, and a list of tables inside the database. It's fine if it's only a couple of tables, but when there's dozens of tables, it gets hard to find the tables I want to edit. I've thought about creating another database to make it easier to organize, but then I'll have to connect using the different database's name and a different user login for the database, and I just thought how much easier would it be if I can make folders or something similar inside the database I already have to organize my tables. I'm wondering if something like this is possible, or anyone know any work-around this issue.
Well, you can't create a database (or folders) within a database; that's just not something MySQL is able to do.
phpMyAdmin has a grouping feature that may help your situation. By default, databases with a prefix followed by _ (a single underscore) will be grouped together, as will tables with __ (two underscores).
Here's an example of how this ends up looking when grouped:
Database:
Table:
If you're able to rename some of your tables, you'll be able to take advantage of the grouping feature to make the phpMyAdmin display a bit more manageable. Of course, this won't change the way other tools display the table list.
The configuration directives $cfg['NavigationTreeDbSeparator'] and $cfg['NavigationTreeTableSeparator'] control the separator used. The relevant documentation starts at http://docs.phpmyadmin.net/en/latest/config.html#cfg_NavigationTreeEnableGrouping and includes the next few line items.
I currently have two tables. One is accounts and one is tbl_units_info. My boss wants me to make it so that accounts are restricted from reading certain rows in a table. Frankly, I think my boss has no idea what he is talking about, but I'm hoping someone here can prove me wrong.
For example, accountname krikara can only view the entries of the tbl_units_info table where the TBID column is 0909.
Is this even possible? To make krikara only able to view the rows in that table where column TBID = 0909?
It can not be implemented plainly on DBMS level since SELECT privilege has table level. You can not restrict rows reading. And this is good, I think - because data could be changed, so in general there is no solid condition for rows restriction (and, therefore, there could not be valid implementation for that on DBMS level).
You can, however, use VIEW - but it is a middlepoint, not common solution (I still not think it will help with tracking rows changes, but may be I'm wrong due to your application logic)
You can try to implement it in your application, but it still has problem I've described above: in table, data is changing. You'll probably have troubles with tracking all changes. I think you can separate your rows on two (several) tables and then build your permissions model. But - if some basically similar entities must have different permissions - probably you should reconsider application security model?
You could solve it by giving accounts just the reading rights to a view instead of the whole table.
CREATE VIEW `tbl_units_info_krikara` AS
SELECT * FROM `tbl_units_ino` WHERE `TBID`='0909';
And then assign the respective rights to your user.
MySQL CREATE VIEW documentation
I am having a main stream website and I would like to include Forum functionality. Since it is a java based system, I opt for Jforum. Now since the JForum having it's own login table and use it from there, I would like to make this to use mainstream login sysem. Can any one post me what are the best practice to do it? Duplicating the data in both the table? Create a view and refresh periodically? I am using MySQL database.
Copying the data from one table to another is not a good idea, as it can introduce inconsistencies in the data. The best solution is to create a View, as you mentioned. Simply add any columns that JForum needs to the main stream website database, and create a view that simulates the table name and column format that JForum is expecting. If done correctly, JForum should simply read from the VIEW which is nothing but a SQL query that changes your existing Users table to appear the way it's expecting it to.