DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Enterprise AI Trend Report: Gain insights on ethical AI, MLOps, generative AI, large language models, and much more.

2024 Cloud survey: Share your insights on microservices, containers, K8s, CI/CD, and DevOps (+ enter a $750 raffle!) for our Trend Reports.

PostgreSQL: Learn about the open-source RDBMS' advanced capabilities, core components, common commands and functions, and general DBA tasks.

AI Automation Essentials. Check out the latest Refcard on all things AI automation, including model training, data security, and more.

Related

  • Unveiling the Clever Way: Converting XML to Relational Data
  • The Evolution of Database Architectures: Navigating Big Data, Cloud, and AI Integration
  • Exploring the New Eclipse JNoSQL Version 1.1.0: A Dive Into Oracle NoSQL
  • Keep Calm and Column Wise

Trending

  • AI-Driven API and Microservice Architecture Design for Cloud
  • The Future of Agile Roles: The Future of Agility
  • Why You Should Move From Monolith to Microservices
  • Integrating Salesforce APEX REST
  1. DZone
  2. Data Engineering
  3. Databases
  4. 5 Simple Rules for CRUD Operations

5 Simple Rules for CRUD Operations

In this article, look at five rules for CRUD operations.

By 
Thomas Hansen user avatar
Thomas Hansen
DZone Core CORE ·
Feb. 11, 20 · Opinion
Like (6)
Save
Tweet
Share
15.4K Views

Join the DZone community and get the full member experience.

Join For Free

CRUD is probably the first word your CS teacher taught you, and you might be thinking there's no way anyone could teach you more about it, right? Well, hopefully I will prove you wrong because once you dive as deep into CRUD as I have, interesting ideas manifest themselves.

For those who don't already know this from before, CRUD is one of those acronyms that we software developers love, and it means Create, Read, Update, and Delete. It is the 4 axioms around which most of our data evolves. If you have all 4 CRUD operations towards your data, your data has an "orthogonal API."

Your relational database evolves around 4 basic SQL statements: Insert, Select, Update, and Delete. It doesn't require a rocket scientist to understand that these 4 words are the SQL equivalent of the CRUD acronym. The SQL version of CRUD hence becomes ISUD. HTTP has the same ideas, but yet again under a different name. HTTP REST refers to these same operations as POST, GET, PUT, and DELETE.

You might also want to read:  CRUD Operation With ASP.NET Core MVC Using ADO.NET and Visual Studio 2017


So the HTTP equivalent of CRUD becomes PGPD. It's important for you to understand that POST is for creating new data and PUT is for updating existing data at this point. The reason is that according to the HTTP standard, if PUT has been implemented correctly, you should be able to transmit the same payload to your endpoint without resulting in changes to your server's internal state. Therefore, updating records multiple times with the same payload does not violate how the PUT verb was intended to be used, since no changes are applied, because the same data for your change is simply transferred multiple times, resulting in no actual change of your underlying data.

Secondly, it's important to visualize the primary keys in your database. All sane databases should have a way to uniquely address one single record in their tables. If one of your tables doesn't have this trait, it's theoretically impossible to reference a single record in it, hence you can insert records and you can read them, but without a primary key, you can never delete a single record, and you can never update a single record (safely!). This is because if there is no way to uniquely identify a single record in your table, any update or delete statement, might in theory reference multiple records.

When I created Magic, which you can see in the video below, I realized that it's all about primary keys — at least from a philosophical point of view. Watch the video first, and then I'll explain what I mean afterwards.

The only reason I could create Magic was because I was able to extract a common "design pattern" in regards to how I treated my data. This pattern is as follows:

  1. All read endpoints return all columns from your table.
  2. All create endpoints do not take any primary key fields, as long as the primary key has a default value. Only if there is no default value for your primary key will create require the client to supply it.
  3. All update endpoints require everything that the create endpoints require, but in addition, they also require all primary key fields to uniquely identify which record to update.
  4. All delete endpoints require only the primary key fields and nothing else.
  5. Create always returns the primary key(s) for the records it creates unless an explicit primary key was supplied by the client. And update and delete always returns the number of records affected.

Once applied, the above 5 simple rules allowed me to, in a generic fashion, read metadata from my database tables, at which point I'd end up knowing my table's column names, which columns are primary keys,  which columns have default values, etc. Once I knew this, I could scaffold code 100% generically, which would first wrap my entire database into HTTP REST endpoints, for then to create an Angular frontend client, consuming my backend, resulting in having my computer automagically create my entire app.

At that point, all I needed to do was to allow for configuring my endpoints by allowing the user to select validators, which roles the client needs to exist within to be allowed to execute the endpoint, etc, etc, etc. In a way, what I did was create my own internal "standard" for how to allow the ideas of CRUD to penetrate securely all the way from my relational database through my .Net Core backend, over HTTP as JSON, and into my frontend Angular data grids. This results in something resembling the following, automatically created for me by my computer.

Customer record

Notice how the primary key for my above Customer record is not possible to edit. In fact, in my Datagrid, I don't even show it by default, but it's there behind the scenes since it's a prerequisite for being able to update my records.

Standardization

I often have junior developers asking me what the difference between a junior and a senior developer is. Often, the answer to this is surprising for the junior, since the junior often knows 15 different ways to implement QuickSort in 10 different programming languages, while the senior has long since forgotten this due to not needing it for 25+ years or something. So I will teach you the difference, and it is "the ability to extract common patterns, standardize on them, and think generically."

In other words, the junior will happily slash away at any problem they are given and try to solve it as fast as possible, while the senior will spend two days thinking about his problem's common traits before even implementing a single line of code. Once the senior is done of course, not only has he solved the problem at hand, but he has also solved every possible permutation of future similar problems. So while the junior is adding to the cognitive and technical debt of his employer, by producing hundreds of thousands of lines of code that needs to be maintained, the senior developer does not do this because every time he solves one problem, he solves a thousand similar problems.

If you want to become a senior developer, stop solving problems immediately! Find the common traits the current set of problems you're working with has with other problems, and extract the commonalities. Then, solve that problem. This will oftentimes result in only 5-10 lines of code you need to maintain in the future instead of tens of thousands of lines of code you need to maintain in the future to keep your "previous solutions running."

I have created software since I was 8 years old, and I am 45 years of age today, which implies I have created software for 37 years. And yes, I still love it! If you want to see how a "super-senior" software developer solves problems, you can start out by downloading Magic.

Database Relational database

Opinions expressed by DZone contributors are their own.

Related

  • Unveiling the Clever Way: Converting XML to Relational Data
  • The Evolution of Database Architectures: Navigating Big Data, Cloud, and AI Integration
  • Exploring the New Eclipse JNoSQL Version 1.1.0: A Dive Into Oracle NoSQL
  • Keep Calm and Column Wise

Partner Resources


Comments

ABOUT US

  • About DZone
  • Send feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: