I have specific demand from my employer. I need to grant INSERT, UPDATE and SELECT access to table A in MySQL to developer_1 and developer_2. They will both insert their own rows into table A, and I will take care which rows are from which developer, through TRIGGER after INSERT. What I need is a way to intercept SELECT statement on any user and to determine which rows can be returned to particular developer. Then I found out that there is no TRIGGER on SELECT! It is really important for me to find the solution because the most important request was that developer_1 cannot see other developers rows. Thanks
just check this link for views, it should be able to help you in your situation
Just create a row where you put something to identify each developer ( I guess you already did that)
Then use this identifier to create 2 different views, each will be allowed to one of the developers, knowing that the views are from the same table
Related
I need to know about one thing in databases.
I have product table with it's total inventory as seen in image
If any one have any idea that how can i do that??
Please Share it
Thanks
What you're asking about isn't technically a "relationship" in the technical sense when referring to relational databases. Such relations are things like having a table that refers to the "key" of another table, for instance relating a table with a customer's address to another table with the customer's order. Anyway, that's beyond the scope of what you asked about so to answer your question, you can do that in the application code or a trigger.
Triggers are features of the database that does something when an INSERT, UPDATE, or DELETE happens.
Something like this should work okay with minor adjustments for table/column names:
UPDATE table2 SET inventory = inventory - NEW.qty where id = NEW.id_product;
Now that only covers an INSERT; you'll want to create another trigger for Event UPDATE and probably somehow handle returned inventory or cancelled orders as well, but that's probably something you'll handle at the application level rather than in a trigger.
I have a database with two tables. The first one contains the user_name, user_password, user_email. The second one contains the user_name, user_age, user_description.
When a person finds the user he needs by the user_name, the script looks through the database using the user_name, to give out the information about certain user.
But if the person changes his user_name via preferences, the value changes only in the first table.
Question:
1) Is there a way to make the user_name in the second table change automatically? (To connect them some how)
I am using MySQL (phpMyAdmin).
This is just a simple example. In "real world" I am trying to manage more serious applications that have more tables. Is there an easier way than to create a separate php query for each table?
You could always create an AFTER UPDATE MySQL trigger targeting single rows for this. See the manual. It's probably not easier than using separate PHP queries for the tables, though. You don't need to spell them all out, just map up what needs to be synchronized when, and abstract your code.
However I'd recommend that you use a unique ID field for the user and only store the username in one of the tables -- and refer to the user with the ID under the hood of your code, and in both tables. Not a good idea to use something changeable as a unique identifier in your database design.
I have the following requirement. I have 4 MySQL databases and an application in which the user needs to get the count of number of records in tables of each of these databases. The issue is that count may change in every minute or second. So whenever the user mouse-hovering the particular UI area, I need to have a call to all these databases and get the count. I don’t think it is a best approach, as these tables contain millions of records and every time on mouse over, a dB call is going to all these databases.
Trigger is the one approach I found. Rather than we are pulling data from the database, I feel like whenever any insert/update/delete happening to these tables, a trigger will execute and that will increment/decrement the count in another table (which contain only the count of these tables). But I have read like triggers will affect database performance, but also read some situation trigger is the only solution.
So please guide me in my situation triggers are the solution? If it affects the database performance I don’t need that. Is there any other better approach for this problem?
Thanks
What I understood is you have 4 databases and n number of tables in each of them and when the user hovers over a particular area in your application the user should see the number of rows in that table.
I would suggest you to use count(*) to return the number of rows in each table in the database.Triggers are used to do something when a particular event like update,delete or insert occurs in a database.It's not a good idea to invoke triggers to react to user interactions like hovering.If you can tell me in which language you are designing the front end I can be more specific.
Example:
SELECT COUNT(*) FROM tablename where condition
OR
SELECT SQL_CALC_FOUND_ROWS * FROM tablename
WHERE condition
LIMIT 5;
SELECT FOUND_ROWS();
The second one is used when you want to limit the results but still return total number of rows found.Hope it helps.
Please don't use count(*). This is inefficient, possibly to the point of causing a table scan. If you can get to the information schema, this should return the result you need sub-second:
select table_rows from information_schema.tables where table_name = 'tablename'
If you can't for some reason, and your table has a primary key, try:
SELECT COUNT(field) FROM tablename
...where field is part of the primary key. This will be slower, especially on large tables, but still better than count(*).
Definitely don't use trigger.
I've come across a slight issue when designing a trigger statement in our MySQL DB today:
We have the following relevant tables:
quote (quote_key, date, discount_rate, discount_period, supplier_key)
part (part_key, part_name, ...)
part_quote (pq_key, part_price, fk_quote_key, fk_part_key)
part_approval (papproval_key, is_approved, fk_part_quote_key)
Now for an explanation of the logic:
Every supplier issues quotes for different inputs into a manufacturing process (e.g. parts and components). If the price for a part is about right, they will be approved for manufacturing and can thus be used by our engineers. Since we want to be able to receive quotes from different suppliers for the same parts to enable a comparison, I've tried to model this process by using the part_quote and part_approval table.
On to my problem: If I want to approve a new part_quote, I would like the BOOL flag "is_approved" in all (or the most recent) old quotes to be automatically set to FALSE.
I tried to get this done by issuing a trigger statement:
CREATE TRIGGER update_approval BEFORE INSERT ON part_approval
FOR EACH ROW --- ??
I have some problems selecting the right rows to update:
How do I select the part_key, which will ultimately identify all relevant rows that require updating?
How do I select only the old (or most recent) rows?
I would have loved to include a screener but unfortunately, I do not have 10reps yet :/
Thank you so much in advance,
All the best,
Marius
First I will answer your question as-is to the best of my ability since it is helpful to know more about how to use triggers. Then I will explain why you shouldn't actually be using triggers.
Triggers provide access to two special aliases, which are not otherwise available: OLD and NEW. NEW lets you access the new values and works in update/insert triggers. OLD lets you access the old values and works in update/delete triggers.
For your case you would probably want something like this:
CREATE TRIGGER `update_approval` BEFORE INSERT ON `part_approval`
FOR EACH ROW
UPDATE `table_x` SET `value` = y WHERE `z` = NEW.a;
For more information and some useful examples of triggers, I would suggest reading this: http://dev.mysql.com/doc/refman/5.0/en/trigger-syntax.html
HOWEVER, triggers in MySQL cannot update the same table which they were triggered on, which is what you are looking to do. There is a good question someone had relating to this here: MySQL - Trigger for updating same table after insert and a good answer that you should use a stored procedure in this case.
I'm not sure this will solve my problem entirely, but based on your suggestions I came across a couple of helpful posts, that were able to implement similar updates within a trigger with multiple statements.
CREATE TRIGGER update_approval BEFORE INSERT ON part_approval
FOR EACH ROW BEGIN
DECLARE part_id INT;
SELECT part_key INTO part_id
FROM part p, part_quote pq, part_approval a
WHERE NEW.part_quote_key=pq.part_quote_key AND pq.part_key = p.part_key;
UPDATE part p, part_quote pq, part_approval a
SET a.is_approved=DEFAULT
WHERE pq.part_key=part_id AND a.approval_date<NEW.approval_date;
END;
will only be able to try it out on monday after the DB has been populated.
thanks for the help!
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