Hi! I want to create a multi language table because AR not support composite primary keys... Now I have 2 table words with one column (id) and localized_word with lang_id, word_id ant the localized text. you know another way? Cow
Háber János <boci@...> writes:> I want to create a multi language table because > AR not support composite primary keys... > > Now I have 2 table words with one column (id) > and localized_word with lang_id, word_id ant the localized text.Probably "Using Gettext To Translate Your Rails Application" (http://manuals.rubyonrails.com/read/book/16) is a good place to look for the Rails-normal way of handling this common issue.
Bill Lazar írta:>Háber János <boci@...> writes: > > > >>I want to create a multi language table because >>AR not support composite primary keys... >> >>Now I have 2 table words with one column (id) >>and localized_word with lang_id, word_id ant the localized text. >> >> > >Probably "Using Gettext To Translate Your Rails Application" >(http://manuals.rubyonrails.com/read/book/16) is a good place to look for the >Rails-normal way of handling this common issue. > >That''s ok, but I want to allow the user modify/add the words. The words table id is a many table foreign key. Example I have a property table where the user can add new propertyes , these properties is multilangual. So that''s the reason why I can''t use gettext. Ohh and user can add new languages for their page. My original thinks I create a composite primary key in the localized_words table (the key is id and lang, id is auto increment, and mysql only increment the id if the "selected" lang is exists). Because AR can''t handle this. My other (false) think is I create YAML file and I store the keyword - localized text pairs in this table, but it''s have many problem in administration (collect all word''s from all table wich not localized, read/write whole table when I modify etc...) Cow
Háber János <boci@...> writes:> Bill Lazar írta: > >Háber János <boci <at> ...> writes: > > > >>I want to create a multi language table because > >>AR not support composite primary keys... Now I have 2 table words with one > >>column (id) and localized_word with lang_id, word_id ant the localized text. > > > >Probably "Using Gettext To Translate Your Rails Application" is a > >good place to look for the Rails-normal way of handling this common issue. > > > That''s ok, but I want to allow the user modify/add the words. The words > table id is a many table foreign key. Example I have a property table > where the user can add new propertyes , these properties is > multilangual. So that''s the reason why I can''t use gettext. Ohh and user > can add new languages for their page.Fair enough. I would disagree with the need for a composite key, regardless of RoR or implementation language, and still use just id as PK with indexes on the fields you suggest make up the ''functional'' key. Just filter at runtime based on the user''s settings. Not sure why this bothers you though, so no hard feelings and perhaps I''m not the person to answer for your specific needs.
Bill, My intention here is not to start a flame war, but the issue of composite keys is one limitation that has given me some pause about RoR. I will say, it has made me look back over my data model [which I control to a large degree in one of my projects] and see if my composite keys make sense and a truly necessary. My initial reaction was yes they were absolutley necessary, but after a critical look all but the following scenario could fall under the RoR way execept my "Rules" table. Here is the situation, I have a table called selections which has an identity column called selections_id. On this table there is also a column that tells me whether or not the pricng for selection is rule based. If it is, then I have code that typically says, I have a group of selections that together in some combintation make up the price for the selection. On the rules table I have 3 ID columns which are actually foreign keys back into the selections table. Since they are unique combinations, I just utilize all 3 of them as my primary key on the table. Now, I could add a column that is an ID column to the table, but in my mind it is a waste of space because it is nothing more than a placeholder just to satisfy RoR. I will say that in most if not all the enterprise app I have worked on we have had Composite Keys that in my opinion were absolutely necessary and fall under this category where you are combining keys from either multiple tables or there unique combinations yeilded something different. I think for RoR to truly succeed, it needs built-in support for not only Composite Keys, but quite possibly those that are character based as well. With that said, I am in the process of attempting a conversion from a J2EE architecture [JSP/SOFIA - Web framework/Hibernate/EJB, etc.] to RoR. Wish me luck! Ron -----Original Message----- From: Bill Lazar [mailto:blazar@gmail.com] Sent: Fri 10/14/2005 2:29 PM To: rails@lists.rubyonrails.org Cc: Subject: [Rails] Re: Composite Key Háber János <boci@...> writes: > Bill Lazar írta: > >Háber János <boci <at> ...> writes: > > > >>I want to create a multi language table because > >>AR not support composite primary keys... Now I have 2 table words with one > >>column (id) and localized_word with lang_id, word_id ant the localized text. > > > >Probably "Using Gettext To Translate Your Rails Application" is a > >good place to look for the Rails-normal way of handling this common issue. > > > That's ok, but I want to allow the user modify/add the words. The words > table id is a many table foreign key. Example I have a property table > where the user can add new propertyes , these properties is > multilangual. So that's the reason why I can't use gettext. Ohh and user > can add new languages for their page. Fair enough. I would disagree with the need for a composite key, regardless of RoR or implementation language, and still use just id as PK with indexes on the fields you suggest make up the 'functional' key. Just filter at runtime based on the user's settings. Not sure why this bothers you though, so no hard feelings and perhaps I'm not the person to answer for your specific needs. _______________________________________________ Rails mailing list Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Ron DiFrango wrote:> Now, I could add a column that is an ID column to the table, but in my mind it is a waste of space because it is nothing more than a placeholder just to satisfy RoR. > > I will say that in most if not all the enterprise app I have worked on we have had Composite Keys that in my opinion were absolutely necessary and fall under this category where you are combining keys from either multiple tables or there unique combinations yeilded something different. I think for RoR to truly succeed, it needs built-in support for not only Composite Keys, but quite possibly those that are character based as well.I agree support for composite keys is desirable. One solution I''ve used when a table has a natural composite key and I don''t want the waste of a separate auto-increment id is to forgo making the table into a model and instead read data from the table into attributes of an actual model by running find_by_sql queries on that model. -- We develop, watch us RoR, in numbers too big to ignore.
Not a flame to me, not like you have to agree with me ;) Anyway, I''m so new to Rails noob is too kind so my point is not from a RoR perspective but rather general database design which I do have reasonable experience. First, to suggest in 2005 that any but the absolutely largest databases need to worry about wasting a couple of bytes per record will never work with me. If the space for the ID and its index adds even 10GB per year call me and I''ll send you the $3.00. (Bill is being facetious here.) Second, if you choose Mark''s approach and avoid the model and associated built-in reduction in code and complexity than I would argue you''re spending developer and QA resources rather than disk space. If that''s what you want, okay, but be clear about it. I think you would lose quite a bit of other help (code that depends on AR and id=PK) so be aware of the tradeoff. Finally, I think this choice was made by DHH and the other developers because they''re aware of the 25 year history of debate over DBMS design. If you look at guys like Celko or Date, they usually go this way (look for "synthetic candidate keys" in the theoretical discussions) and I will defer to their authority. YMMV, Bill Ron DiFrango wrote:> Bill, > > My intention here is not to start a flame war, but the issue of composite keys is one limitation that has given me some pause about RoR. I will say, it has made me look back over my data model [which I control to a large degree in one of my projects] and see if my composite keys make sense and a truly necessary. My initial reaction was yes they were absolutley necessary, but after a critical look all but the following scenario could fall under the RoR way execept my "Rules" table. > > Here is the situation, I have a table called selections which has an identity column called selections_id. On this table there is also a column that tells me whether or not the pricng for selection is rule based. If it is, then I have code that typically says, I have a group of selections that together in some combintation make up the price for the selection. On the rules table I have 3 ID columns which are actually foreign keys back into the selections table. Since they are unique combinations, I just utilize all 3 of them as my primary key on the table. > > Now, I could add a column that is an ID column to the table, but in my mind it is a waste of space because it is nothing more than a placeholder just to satisfy RoR. > > I will say that in most if not all the enterprise app I have worked on we have had Composite Keys that in my opinion were absolutely necessary and fall under this category where you are combining keys from either multiple tables or there unique combinations yeilded something different. I think for RoR to truly succeed, it needs built-in support for not only Composite Keys, but quite possibly those that are character based as well. > > With that said, I am in the process of attempting a conversion from a J2EE architecture [JSP/SOFIA - Web framework/Hibernate/EJB, etc.] to RoR. Wish me luck! > > Ron