Plan Feedback

[sumeetjain]

• "Store a database of common translations" ... "Search database for matching text" ... You don't really mean these will be separate databases, do you? Can you reword this correctly?
• "Add new translation records by user" ... "Separate search of user database for matching text" ... I'm having trouble parsing these statements. Can you write them as fuller sentences?
• Relationships need to be defined in terms of models. What are your classes going to be? What are the foreign keys in your tables going to be? How would you describe the relationships between each of your models?
• I'd like a diagram similar to what I asked for for the warehouse manager project.

[jhogrefe]

Got it. Will clarify and get back to you!

[jhogrefe]

Sumeet, is my project too rudimentary? I am mapping out the functionality and it just doesn't seem beefy enough. I don't know if my frustration is causing a mental block for modeling it out. I seem to be going around in circles. Based on my attached image, I only have an "admin" section (no login required right now, just will be a different URL location) that adds, edits and deletes translation records. Which means I only have a single table for my database. Unless I add a custom_translations table that stores query strings from the user (when using the Microsoft Translator service) and then also stores the returned translation text. That would still only give me two tables. What are your thoughts?

[sumeetjain]

Start simple: Your project shall only be for getting the translation of a term in SPANISH. That's all.

I think you would have two tables for sure:

terms translations

And their related classes are Term and Translation. A single term can have many translations. A translation belongs to a single term.

If you're struggling to understand these relationships, try going back to dinner club and warehouse, and examine the relationships in those projects.

It's fine if you only have these two tables right now. Your next task can be adding the table that's needed to allow the program to store translations in many languages. Keep posting questions and versions.

[jhogrefe]

I took a break and came back to it, and came up with the attached. I can see having 3 tables for terms, languages and translations, with their respective classes: Term, Language, Translation. I put together how they would associate (one term can have many translations; one term can have many languages; and I think there is only a one-to-one relationship between language and translation in my project, as you can see in the output table...not sure if that is supposed to be its own table or just the setup for how output happens):

[sumeetjain]

It helps to come up with exact examples. Right now, I think you have a mistake in your understanding of the relationships. Build the tables out to about 20 rows each, with "real" data. Make sure you can use that data to accomplish the "shoulds" for the application.

For simplicity's sake, start with terms only being in English: I type in "save as" and get back a list of translations in various languages.

(By the way: This might feel like time being lost – time which could otherwise be spend coding. It's not. This is time being saved. It's time you would have otherwise spent banging your head against a wall on Wednesday. Since you run a software shop, you're probably familiar with the concept of "technical debt". This is how we reduce it :smile: )

[jhogrefe]

Ok, I will create some tables with real data and make sure it works the way it should.

I was always planning on terms to only be in English anyway (this website would only translate English to other languages), so not sure if that would make any difference.

[jhogrefe]

Sumeet, I feel like I am pigeonholing myself into something more difficult that what was originally in my head. I think the project is too simple, forcing me to find more difficult ways to fit the requirement scope of multiple relationships.

In my head there is simply a single table for "translations" (you can see below).

I only ever wanted four supported languages but I can see if I ever wanted to add additional ones I could create more and link them to the original table with a column for translations_id (foreign key for translations table).

I thought I had a way to break apart the translations into terms, languages and translations (previously attached), but you told me that did not work either, so I am completely confused on relationships with this project. Like I mentioned before, maybe I am forcing myself into a mental block because I am trying to figure out how to make multiple relationship models work with this software translation project. Instead of banging my head against the wall this week, I have been doing it all weekend! Ugh.

[sumeetjain]

I thought I had a way to break apart the translations into terms, languages and translations (previously attached), but you told me that did not work either...

I don't think that's accurate. I said that I think there's a mistake in the relationships and that you should write out an example database with about 20 "real" records in each table. If you post that, I bet we can make progress.

I think you can absolutely have three tables:

• terms (stores each term that someone asks for a translation of)
  • One important column called "text" (or something)
• languages (stores the languages that something can be translated into)
  • One important column called "name" (or something)
• translations (stores a translation for a given term)
  • Three important columns called "translated_text", "term_id", and "language_id" (or something)

These are the tables you had above, where I suggested you write out the real data. It's tempting to just write our 4 or 5 fake columns with squiggly lines and blank spaces instead of real values, but I would strongly encourage you to actually do "real" values. Thinking about what the real values would be is where clarity of database design comes from.

The mistake I believed you had was not in the definition of the tables but in how they relate to each other ("relationships"). I think writing real data will help clarify that.

[jhogrefe]

I built out the tables:

I hope my frustration with my lack of understanding hasn't come across as snippy. I'm not unhappy with your instruction it's just unfortunate the weekend happened. I was really looking forward to working on my project...

Sent from my iPhone

On Feb 15, 2015, at 12:21 PM, Sumeet Jain notifications@github.com wrote:

It helps to come up with exact examples. Right now, I think you have a mistake in your understanding of the relationships. Build the tables out to about 20 rows each, with "real" data. Make sure you can use that data to accomplish the "shoulds" for the application.

For simplicity's sake, start with terms only being in English: I type in "save as" and get back a list of translations in various languages.

(By the way: This might feel like time being lost – time which could otherwise be spend coding. It's not. This is time being saved. It's time you would have otherwise spent banging your head against a wall on Wednesday. Since you run a software shop, you're probably familiar with the concept of "technical debt". This is how we reduce it )

— Reply to this email directly or view it on GitHub.

[sumeetjain]

Nope, you haven't come across as snippy – and it wouldn't matter if you had.

The weekend was still valuable time spent. This is working on your project :smile:

The image didn't come through – probably an issue with adding comments via email.

[jhogrefe]

Here you go:

[sumeetjain]

Nailed it. This is the right database structure. For tomorrow, I'd like you to have the right language to talk about the relationships being indicated here. But for now, :+1: :rocket: