Last question for today, I promise…

For my side project, I plan on saving a URL and an array of strings associated with that URL. I want to be able to search and sort the resulting DB from a frontend without needing complicated queries. Is this the use case for a key-value pair DB? Let me know if I’m not clear and thanks!

search by what? By URL? yes. By strings in the array? not really.

What will be in the array of strings ?

Unless you use some kind of ORM, you will need sql to get the data you want.

@Grumm assuming it's in an SQL database, that is

@ScriptCoded Yes, but based on the question I doubt he will be using MongoDB. (But it will probably be the best option for what he wants.)

@Grumm we'll he's saying he doesn't want to query the db 😅

@netikras search by the strings in the array unfortunately. It seems like key-value pair DB might not be the best option after reading the comments

@Grumm the strings are SEO keywords for the individual URL. Since a lot of the URLs have the same keywords, it’d be great if I could search and sort by them

@ScriptCoded @Grumm still haven’t decided whether I should use an SQL DB or not. I’m very open to any and all suggestions

Why the front end needs to search and sort?

that's backend's work, remember, the front end just prints pretty processed data.

It would be also a waste to search and sort from every frontend invoking the url from the backend

@arcioneo I'd argue that search and sort in FE are useful. Consider a table with optionally sortable columns. And an input field for a filter. Would it be more efficient if 1000 computers asked your single DB to do the filter/sort upon each click? Or would it be perhaps more efficient to filter/sort in those additional 1000 computers you get for free?

Also, consider the responsiveness

@netikras that depends on what are you planning to do with such data.

for example, let's consider this map/db/whatever it is has 10,000 rows, what would it be the bandwidth required to send those 10k rows to 1,000 users?

Again, it all depends on requirements, but, as a general good practice, data should live in BE, you can use pagination to limit the amount of data sent to the FE and even make it more efficient by caching the table(using Redis or something like that).

again, it all depends o what are you trying to achieve

@arcioneo I agree. Listing the whole shop's stock in single request is definitely suboptimal. However, fetching all the immediate friends on Facebook and caching locally might be an option (that's what, ~300 entries?).

Depends entirely on quantity.

So far you've said that you have an relationship of URL to SEO keyword.

Let's spin some hypothesis.

You have 10 distinct URLs.

You have 10 distinct SEO keywords.

You could solve this by just defining two lists and using an third object to define the mapping - creating an mini database based on simple objects.

Simple, crude - effective.

If we're talking about hundreds of SEO keyword and hundreds of URL I could understand an database, but if it's small, there's no need to involve an database.

Next question would be what kind of relationship you want: an 1:N or N:M.

In an 1:N you would define for each URL an list of SEO keywords.

In an M:N you would have a list of SEO keywords that is linked to one or more URLs - meaning that you define each SEO keyword only once and each URL only once and create an association between them.

The first case would be an good case for key value - nothing fancy.

Second case would be an good case for an RDBMs - as it isn't "strictly" key to value, but rather a key of a value to another key of an value - as the SEO keywords are one list, and the URLs are another list and you only reference them via their keys.

You could use an embedded, simplified database for that - depending on language, there exist quite a few.

For anyone interested, I need up using mkDocs and the mkDocs-material theme. It’s a static site generator that creates pages from markdown files. It also has a built in search feature too which is extremely useful