Tags that a search can actually trust
A blog tags its posts. A post has any number of tags, and tags are shared across posts.
What the product needs:
- Find every post carrying a given tag, and exactly that tag. Searching for
sqlmust not return a post taggednosqlorsql-server. - Count how many posts use a tag, for the tag cloud.
- The same tag cannot be attached to the same post twice. It is either on or off.
- A tag can be renamed, and every post carrying it follows automatically. Marketing does this and does not warn anyone.
- Tag names are unique: there is one
sql, not one per post.
The tests read through two relations you provide: tags and a way to connect
posts to them. posts already exists.
The contract
3 relationsThe tests reference these names. Everything else is yours, and is what is being assessed: extra tables, extra columns, types, constraints, indexes.
posts
idtitle
tags
idname
post_tags
post_idtag_id
The schema that already exists
This runs before your submission. Do not repeat it, extend it.
CREATE TABLE posts (
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
title TEXT NOT NULL
);
INSERT INTO posts (title) VALUES ('Indexes explained'), ('Why we left Mongo'), ('Cooking');Nothing here yet. Run the tests while signed in and every distinct schema you submit is kept, newest first, so an earlier design can be read next to the one you would write now.
This one is for subscribers
The problem above is the whole problem, and nothing is hidden from it. What a subscription adds is the part that tells you whether your answer holds: a real Postgres runs your schema, a battery of hidden tests decides, and a design review reads what you wrote.
Checking your subscription…
