zompist bboard

Chuma wrote:I'm not sure why you would need a rank 3 array. I would have guessed roots on one axis, patterns on one axis, and for each entry the English word (and the conlang word, if that's not completely obvious from root+pattern). Then you could search for either an English word, a conlang word, or a root+pattern, and see all matching entries, or you could search for a root, and see a list of all patterns which are possible with that root (and perhaps their whole entries).
Is that what you need, or are there any other searches you need to be able to do?

Guitarplayer wrote:Chuma, I think you're suggesting basically what a Join does, except you'd deal with dynamically generated results instead of a static list:

Code: Select all

SELECT root, pattern, translation
FROM tbl_root, tbl_pattern, tbl_translation
WHERE root LIKE "x-y-z"
   AND tbl_root.root_id = tbl_pattern.root_id
   AND tbl_root.rood_id = tbl_translation.root_id;

Something like this. At least that's kind of what I'm doing for my database. And for the purpose of a dictionary IMNSHO a properly set-up relational database is not useless or overkill. And you can generate derivative lists in different formats easily.

Zoqaeski wrote:the 3rd dimension could list fields such as conlang word, pronunciation, English meaning(s), etc

Guitarplayer wrote:Something like this.

SELECT root, pattern, translation
FROM tbl_root NATURAL JOIN tbl_pattern NATURAL JOIN tbl_translation
WHERE root = "x-y-z"

personak wrote:Lexique Pro is great.

Chuma wrote: Phew, I feel like I've forgot all about SQL. Let's see... what tables might we have?

tbl_root (root_id, root)
tbl_pattern (pattern_id, pattern)
tbl_translation (translation_id, translation, root_id, pattern_id)

Then you should be able to do

Code: Select all

SELECT root, pattern, translation
FROM tbl_root NATURAL JOIN tbl_pattern NATURAL JOIN tbl_translation
WHERE root = "x-y-z"

I'm not sure I understand your way of doing it - why does tbl_pattern have a root_id?

Anyway, that should work, but it doesn't sound like the simplest way to me. Not sure how clever the SQL interpreter is, but if you do a straight join it would have a huge list to look through, so that's hardly effective (not that it should matter unless you have a really huge lexicon).

Basically all you need is one ordinary table. I also assume that you have a finite constant number of patterns, which makes things easier if you store the table in a file. You just make a list, where each line has the different patterns for a single root. That seems much easier to me than making an SQL database just for this one wordlist. But hey, do as you like.

sano wrote:

Zoqaeski wrote:What I don't really understand is whether I can actually store the database as a table reminiscent of an addition or multiplication table, because logically root + pattern = word. If I give IDs to every root and pattern, the cells could be identified by some kind of mathematical relationship, and each cell could then consist of a "document" containing the necessary information fields.

Zoqaeski wrote:Reading some of the SQLite (and SQL in general) documentation, it seems that the best idea will be to have separate tables for roots and patterns, and searching performs a join.