Thanks. I think my setup should work. May not be perfect, but it'll do the job. It was mostly an educational question, since I don't think the performance will be an issue at least for a long time to come.
Since my plan is to look up dictionary entries, and the actual information that I'll be searching for is inside the 'readings', I'm guessing I'll do a matching query of some sort on the dict_reading.reading. At the moment I don't see much need for anything other than a full match query (so no partial matches will be needed). I'm thinking I'll at least set index=True on that col. In case I have an entry and want to find associated readings, I'll need an index on the dict_reading.dict_entry_id col as well. I'm sort of new to this, it's been a long time since I've done any serious backend work. Still getting back into things! Michiel 2014-12-25 1:06 GMT+01:00 AM <[email protected]>: > My general suggestion for 'optimality' questions is to not worry about it. > > Start with a schema that seems natural and maps well to the problem you > are trying to solve. Once you have it setup and working, then and only then > focus on whether it needs to be optimized/denormalized etc etc. In a large > percentage of the cases, for the loads that are demanded of db backed > applications, IME one almost never needs to change the original schema. > > What would help more is to focus on the 'kind' of queries you are going to > have and make sure you index the appropriate fields. > > HTH > AM > > On 12/24/14 12:33 PM, msikma wrote: > >> Hi there, >> >> I've got the following schema: http://pastie.org/private/ >> w3oyxp5yjqggtiorknz6q >> >> Am I doing things right? To explain what I'm trying to do: right now, I'm >> trying to parse a dictionary file (edict2). It consists of dictionary >> 'entries', each of which have some basic information, then multiple >> 'readings', and multiple 'tags'. (And definitions, but those will come >> later.) Each reading item itself can also contain multiple 'tags'. >> There will not be too many connections per entry, but there will be many >> (170,000+) entries. >> >> So I've made two relationship tables. I think this should work. But I'm >> not sure if it is optimal. In pure SQL I'd probably do a (id, id) primary >> key. Right now it generates this SQL: http://pastie.org/private/ >> an5kiotkqgatl4tre3x4q >> >> I'd just like to set this up as properly as possible from the start, so >> maybe you have suggestions on what I could improve? >> Thanks! >> >> Michiel >> -- >> You received this message because you are subscribed to the Google Groups >> "sqlalchemy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <mailto:sqlalchemy+ >> [email protected]>. >> To post to this group, send email to [email protected] <mailto: >> [email protected]>. >> Visit this group at http://groups.google.com/group/sqlalchemy. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
