Welcome Guest, Not a member yet? Register   Sign In
CRUD applications to update MYSQL database

This is a broad topic i think needs more documentation. My question relates to overcoming database constraints without compromising date, security. I have database constraints that disallow my crud from updating table rows i want updated. For instance you cant update the child rows of a database without going to the parent.  I am looking for much more guidance on best practices for crud applications. Is it a good, feasible practice to then call two tables at once weaved together so the crud can update the primary target table? Is it bad practice to run crud application on such tables? Is it a good practice to use a query for the crud application goals instead?  Is it wise to simply turn off all the restrictions? I can restrict the crud to a limited set of forms but i would like to reach more if not all tables, the database restrictions are a major obstacle to that. I see clearly that i can simply skip the problem column in question. I need the freedom to update that column so my administrator section can update the target item. Every crud example i have seen so far fails to reach the desired depth or goes so deep the application becomes unstable. I am ok with one crud application for each table but i would be more happy with one crud application that could handle the diversity of all tables, their specific constraints. If i am to continue with one crud application per table i want to hear back from someone who has been there before.

Constraints are put on a database to protect the data.

Why should you be able to delete an invoice if it belongs to an exsiting customer and is out standing?
What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )

its depend how the database is designed. restructured database and remove constraint if need. make sure some table independent (required delete but need to retain parent data)

(09-15-2021, 01:09 AM)InsiteFX Wrote: Constraints are put on a database to protect the data.

Why should you be able to delete an invoice if it belongs to an exsiting customer and is out standing?

Constraints was probably a poor choice of wording, although ironically i am also having problem with column check constraints in mariadb 10. I setup some basic column constraints while the dbase was in access that imported in perfectly, now i am finding that mariadb rejects virtually any call for a new column check constraint. Perhaps I will have to go back into MYSQL workbench to see if it can overcome the syntax gap. I have tried many variations of syntax using the case statement and then fell back to a simple check statement. I am having no trouble with the tables, queries at all. 
I have got the basic crud application to work for all phases of user registration. I have also succeeded in setting up a more advanced crud authored by alex lancer with admin lte. My base website traverses all links, using bootstrap. The challenge i didn't expect was that i would have to do joins within the controllers for the crud to gain permission to update, delete. Customization seemingly puts my built in security at risk. The parent/child error is currently at issue on my most recent crud in a new table.  I intend to try a left join to resolve crud refusing to update a table with a foreign key next. I think i have found such a crud project to follow.

OK so i have solved my primary indexing issues in 2 steps. 1 by simply changing my primary key selection( misinterpretation of my key at issue ), 2 by flipping the variable chosen for some of my loops, my oops on that one! Since the keys are really important to my database i backed up the table separate from my database backup before proving out the crud. I have chosen to allow changes on different columns in my model rather than all (all columns not practical) ---protected $allowedFields = [ 'a', 'b', 'c' ];. I will only list my important columns , the target columns where updating is truly needed i will try to setup soft deletes, update tracking on those fields in the adjoining html form next.

Theme © iAndrew 2016 - Forum software by © MyBB