How are you doing it? I would think the best structure to it would be having an item card table structure table and an item card data table, then link the item data to the structure table. If the structure returns >1 results, then it's double sided (you can have an 'isBackSide' toggle in the data structure for things)

Then just the option to aggregate or not aggregate if you desire.

Actually, thinking about it, better design would be Item Table that's got the image and title, then the item data that's the description, and a join table that can link the two, then when you do the query it could easily find everything.

my current plan is have a isdoublesided flag and have a separate datafields column that holds the raw json for the reverse side same as the front side is currently being stored.

Then when you only want it display the front side of backside for whatever reason (say, you're setting up the actual print) you can set a flag "frontside only" and "backside only" the front end can interpret.

Fair.

the upshot is the DB makes a little more intuitive sense and I don't need to change my data objects much for the refactor.

Yeah, I can see that. I was thinking of it the way I described as a way to keep the data kind of uniform, for lack of a better term. From the system side, it's all item data that's linked to a "Card" object. It's probably designing for an ORM in my thinking.

Your way works too, though in my mind you still need a flag to tell the FE that a particular item card needs to be interpreted as specifically the front or back side.

Yeah, just a bool in the data that says 'isBackSide'. If the query of the main item only returns one data result, it could be ignored, since it wouldn't matter.

The issue is I want to keep the API endpoints simple. So I also need a "IsFrontOnly" option as sometimes you'll want only the front item to be in a particular place.

Would isFrontOnly ever apply to double sided cards?

Because otherwise, if the join table query only returned one set of 'side' data, it could just be considered single sided, and the isBackSide would only apply if the join table query returned more than one side.

Yes. I'm imagining how the front end would display pages for printing. Assume 9 cards in a grid, rows 1-3, columns A-C. Only the front would be on at grid 1-A and only the back would be Grid 1-C

To simply how the front end returns and item, you'd want the flags to be set correctly for both the front on page 1 and back on page 2.

Ah, I see what you're saying. Honestly, you could probably just set an enum on the table with either Front or Back, and do it like that. Not as simple as a boolean, but still fairly simplified

Yeah, I was thinking about an enum but decided booleans allow for a little more simplicity of instruction.

Fair. I might just be thinking on an enterprise scale for things, because ideally you'd want to return the smallest amount of data that you needed, but I doubt that we'd hit a scale where it would be difficult.

Yeah, if someone is trying to print every character and item card in the DB at once... something is wrong. And if the DB is returning 30-60 character sheets with items at once, it only needs to do it once, so I'm willing to not care about wait times.

Also in the back end I can whittle down a lot of the unneeded data pulls for backside only items.

I mean, I did that for the second neko con. With Quark files.

But, it was a different time.

Neko is different though. And the whole point of the DB system is to make it so that's not ever needed.

You need a sheet? Three clicks and it's printed at con.

And honestly, I'd see it as being more apt to have a printout of most of the item cards so they can get stuffed into a binder for quick access. Sheets, yeah, those not so much.

But, in the end, both methods are good.

Oh yeah, the items will be meant to be printed en masse for binder printing, but even THEN that's another kettle of fish.

Once you're done with your projects, I've got some basic migration to net8, since 7 is completely depreciated.

all good.