Object Hierarchy Database Thing

Getting Help
1

I have a nuisance that I want to search for an answer to. When writing object oriented programs, MySQL’s layout doesn’t match my object hierarchy. For instance, look at the following Go code:

type Para struct {
    Summary string 
	ParaText string
    IdunnoSomeOtherThing string
}

// Carry object is an object that represents the full story
type CarryObj struct {
	Author     string // USername of the person who wrote this
	StoryNdx   int    //
	StoryTitle string
	FullText   string
	Paras      []Para
}

Paras are always going to be multiple sub-units of CarryObjects. To save them to a mysql table, I would have to create a separate table that has columns for the paras and the para row would have to use that column to point back to the carryobject that contains it, probably through an index of some kind. Is there a database that would take the hierarchy into account natively without needing to wrangle a sql database with a bunch of tables and foreign keys?

2

This seems like a very simple table structure with a one-to-many relationship. SQL can model that easily:

CREATE TABLE carry_objs (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    author VARCHAR(255) NOT NULL,
    story_ndx INT NOT NULL,
    story_title VARCHAR(255) NOT NULL,
    full_text TEXT
);

CREATE TABLE paras (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    carry_obj_id BIGINT NOT NULL,
    summary TEXT,
    para_text TEXT,
    idunno_some_other_thing TEXT,
    
    FOREIGN KEY (carry_obj_id) REFERENCES carry_objs(id)
        ON DELETE CASCADE
);

That said, maybe you want a document-ish database if you don’t want to worry about tables/foreign keys? You could try Mongo:

And I’m actually currently working on the Go Client for DataStax Astra DB:

It’s not to V1 yet (still building it!) and it’s probably overkill for a hobby project, but, they have a generous free tier. And if you had any questions/problems, I would obviously be around to help you.

Anyway, maybe share some of your Go code that is causing headaches and I can diagnose what’s going on. But - like I said, this sounds like SQL bread and butter to me. BUT - if you just don’t want to bother with SQL and stuff a bunch of JSON somewhere and then retrieve it quickly, document database might be what you are after.

1 Like
3

There really isn’t any code to show yet. I’m just thinking through what I want this project to look like.

4

I am experimenting with S3 Object Storage as document storage. Seems to be both cheaper and simpler. And the database is not growing that fast…

5

I mean - Object Storage is generally solving a different problem. Like how do you query your S3 data for documents with a property called genre with a value of “fiction”? Are you storing metadata somewhere? No matter what you do, the latency is going to be higher than a NOSQL DB.

6

You store the metadata within Postgresql (etc) with a bucket + url to the object. If the purpose is to store objects, you upload directly to the Object Storage. And when you download the object, you get a one time link for direct downloading from the Object Storage. So I assume that the latency with a direct link will be as low as NoSQL?

TBH I have no experience of NoSQL (except from storing JSON inside Postgresql – Best of two worlds?). You may be correct, but as I avoid JSON (assume that this is the “language” of NoSQL?) as I find a “normal” database simpler to query, join etc.