There's a couple different ways you could approach the problem. One, is you could just create a north/south/east/west field as you show here-- that may be workable, if you're on a MUD with very consistant exit-naming.
Another would be to add a separate sheet, like:
Code: Select all
local roomdb = db:create("AetoliaRooms",
{
rooms = {
num = "",
title = "",
environment = "",
_index = { "title" },
_unique = { "num" }
},
room_exits = {
num = "",
exit = "",
target_num = "",
_index = { "num" },
_unique = { {"num", "exit"} },
},
room_attributes = {
num = "",
mark = ""
_index = {"num"},
_unique = { {"num", "mark"} },
}
}
)
Generally speaking, databases can only hold scalar values in a given field. If you want complex values, that's usually an indication that you actually want a w hole new table-- er, sheet-- and a relationship between the two sheets. In the above, the "num" field creates the relationship. Now, in real SQL, you'd create a foreign key and define certain protections to ensure said relationships are always valid. Like, "if I delete a room, all the exits and marks related to it should be deleted too." SQLite doesn't support that, and the db frontend doesn't add that on top-- so you have to be sure that if you do delete a room, you go clean up the related tables too.
Now, that said, I'm tempted to tweak db.lua to serialize tables into strings, and vice-versa, so you can store arbitrary table-ish-stuff in fields. But that would only work for basically simple tables (e.g., not things with metatables or weird custom types).