Looking for good literature regarding CRUD. Basically i want to have a list of possible dataoperations nowadays. And the relations to commands like Copy, Paste, Search, List, Undo Redo, Macros etc. Any suggestions?

REST or GraphQL come to mind, but both are designed to work over http.
A lot depends on context here - are you working on desktop app, web app, database?

I understood that you wanna CRUD these operations and unsure about the naming?

@impune-pl

There is a saying that those who dont understand linux are bound to develop it again - only worse.

Answering your question:

Both not. My aim is to get a grasp of the scale of how data is being used nowadays and extrapolate the usecases sorrounding it. Any information regarding that would be appreciated.

I have the feeling that in any application I develop, I arrive at core problems on how I need to scale the app I am sure others have faced them before me already but coming up with solutions feel kinda reinventing the wheel.

The datalayer is the base for all which can be possible, so I am focusing on that currently.

A search on wikipedia regarding CRUD yielded base operations on Data. Are there more? And if yes how many? What usecases are there?

Examples going in the direction I mean. Sorry comment got too old.

A search on wikipedia regarding CRUD yielded base operations on Data. And these things , which mostly seem to be the same or can be replicated by CRUD.

ABCD (add, browse, change, delete)

CRUDL (create, read, update, delete, list)

BREAD (browse, read, edit, add, delete)[6]

DAVE (delete, add, view, edit)[7]

CRAP (create, replicate, append, process)

Are there more? And if yes how many? What usecases are there?

@rantsauce

Not the naming. The relationship between Data and their Operations.

Maybe something like a Mindmap how the Base operations like CRUD are related to Compound(?) Operations like Search, List and then being combined to common known Commands in Applications like Undo, Redo, Macros.

And then literature about this topic if it exists.

@noyb Well it's mostly just made up bs for a catchy name.

Create, patch, remove, etc. are pretty self explanatory I guess. I wish I could help you more but it's not a very deep topic

@noyb For "complex" operations you won't find a one-size-fits-all explanation

Undo/redo is generally implemented by a list that stores what operations where performaned so you know what to undo

Search and List (?) are (extremely) complex and have no general solution. Searching a word document and searching a phrase on google are nothing alike

@12bitfloat

I read somewhere that the Update part on data is sometimes discouraged and another Insert is being used instead. E.g Logging or in Git updating a pushed commit or editing a commited one is not possible is it? This paradigm change to the basic CRUD is something which interests me. If i would recreate git. I would need strong reasons as to why I would omit Update Operation on a dataset like a pushed commit.

@noyb That's very use case specific as well. If you want immutable data then you could use copy on write, but generally you just update the data

@noyb there's a pattern called the Event Sourcing pattern that has some advantages at scale over updating https://learn.microsoft.com/en-us/...

Imho the question is valid, though it needs another "source of origin".

Most of these acronyms and their pros / cons are directly linked to the service "hosting" the database.

It's an entirely different game comparing an relative database management system vs an key value store vs an in memory database vs an inverted index search engine - and these are just broad and general terms, not even specific terms (think of e.g. compound key specific databases like Scylla)

That's the reason why one should think first about what type of data is used and in which way, then about quantity of data and frequency of simple operations and then - and only then - one should make their mind up about what service they use.

It's always a guess, the more facts, the better.

E.g. massive inserts / deletes / updates are in an inverted indices database the number one thing you don't want - as this leads to a lot of fragmentation...

In a database based on a "tombstone" concept where data can be stale, no biggie.

I’d say the basic operations are just Read and Write.

List and Search is Reading.
Create, Update, Delete is Writing.
Other operations are combinations of both.

@Lensflare

Thats exactly where I want to go Lens. And for what I´d like to find some literature regarding that. With the questions like: What combinations exists and how are these combinations based on the core operations available? Similar to math (as computing anything is based on math) how power-of operations can be broken down to multiplication and then to addition <--- which is then the base operation.

@spongessuck

Thank you very much! Never heard of that. Seems very interesting to my question.

@IntrusionCM

Is there good literature or other sources you can suggest? The approach you mention interests me. I dont come to those type of questions very often in my day job but when I need to develop everything for my projects its another game. I can setup databases and some easy relationships but the approach about the data allures me.

@noyb

I honestly don't know if there are books that cover this.

Afaik most focus (sadly) on RDBMs (relational database management system) as this is what is taught in universities... Sadly mostly on the theoretical layer (normalization, mathematical background etc).

"Databases" as a very broad term is I think a vast field.

https://en.m.wikipedia.org/wiki/...

Wikipedia article, classification section highlights that problem I think very well.

If there is an book or anything like that online available, I'd be most interested in it...

My knowledge stems mostly from reading a lot of planet blog aggregations online and my approach to always question the status quo.

E.g. I found about Scylla as I was dealing with a rather pesky situation where I had a database which had parent child associations... Compound indices. Which are an RDBMs nightmare, as they become very inefficient very fast.

(compound indices are usually realized in an RDBMs by creating a sort of linked list of primary key to all fields of the index, so you have a size of primary key column plus sum of all columns data types. This can be quite a heavy burden, especially with write intensive loads)

https://docs.scylladb.com/stable/...

The other thing that made Scylla interesting then was the partitioning...

... And the documentation. For me a database system without good documentation is a red flag and a big no.

So I stumbled on Scylla because I really saw the database design and thought: Fuck no. There must be something specialized in this - an RDBMs will drown in that kind of data.