Pseudo array for Rails migration

[Ralph Shnelvar]

Consider


N_X = 20 # size of pseudo array

class CreatePeople < ActiveRecord::Migration

create_table eople do |t|
t.string :first_name , :null => false

 

[Robert Klemme]

Consider


N_X = 20 # size of pseudo array

class CreatePeople < ActiveRecord::Migration

create_table eople do |t|
t.string :first_name , :null => false
.
.
.
t.integer :x00
t.integer :x01
t.integer :x02
.
.
.
t.integer :x18
t.integer :x19


t.timestamps
end
end



What is the (best) way of generating the "t.integer :xYY" (where YY is
00 through 19, inclusive) which is dependent on N_X.

What stops you from doing

N_X = 20 # size of pseudo array

class CreatePeople < ActiveRecord::Migration

create_table eople do |t|
t.string :first_name , :null => false

 

[Ralph Shnelvar]

RK> What stops you from doing

RK> N_X = 20 # size of pseudo array

RK> class CreatePeople < ActiveRecord::Migration

RK> create_table eople do |t|
RK> t.string :first_name , :null => false
RK> .
RK> .
RK> .
RK> N_X.times do |i|
RK> t.integer(("x%02d" % i).to_sym)
RK> end

RK> t.timestamps
RK> end
RK> end

RK> ? Btw, having columns with indexes in their name is considered bad
RK> schema design because you either could normalize it into another table
RK> and join or provide more meaningful names instead of "x02" if it is used
RK> as a placeholder. My 0.02EUR.

RK> Kind regards

First of all, I'm a noob. I should have said that.

Thus your solution
(1) Makes sense.
(2) Explains a lot about Ruby.

For both I thank you.


In terms of normalizing the database, I ran some timing tests and
normalizing it slows me down a couple of orders of magnitude. I'm
willing to live with the lack of purity for the sake of performance.

 

[Marnen Laibow-Koser]

Ralph Shnelvar wrote:
[...]

RK> ? Btw, having columns with indexes in their name is considered bad
RK> schema design because you either could normalize it into another
table
RK> and join or provide more meaningful names instead of "x02" if it is
used
RK> as a placeholder. My 0.02EUR.

RK> Kind regards

First of all, I'm a noob. I should have said that.

Thus your solution
(1) Makes sense.
(2) Explains a lot about Ruby.

For both I thank you.


In terms of normalizing the database, I ran some timing tests and
normalizing it slows me down a couple of orders of magnitude. I'm
willing to live with the lack of purity for the sake of performance.

A couple orders of magnitude? This suggests to me that your
normalization and/or queries are poorly done. What is chewing up so
much time, and what does the normalized schema look like? It should be
possible to find a solution that performs reasonably and doesn't have 20
repeating fields.

Best,

 

[Robert Klemme]

Ralph Shnelvar wrote:
[...]

RK> ? Btw, having columns with indexes in their name is considered bad
RK> schema design because you either could normalize it into another
table
RK> and join or provide more meaningful names instead of "x02" if it is
used
RK> as a placeholder. My 0.02EUR.

RK> Kind regards

First of all, I'm a noob. I should have said that.

Thus your solution
(1) Makes sense.
(2) Explains a lot about Ruby.

For both I thank you.


In terms of normalizing the database, I ran some timing tests and
normalizing it slows me down a couple of orders of magnitude. I'm
willing to live with the lack of purity for the sake of performance.

A couple orders of magnitude? This suggests to me that your
normalization and/or queries are poorly done. What is chewing up so
much time, and what does the normalized schema look like? It should be
possible to find a solution that performs reasonably and doesn't have 20
repeating fields.

I second that. Ralph, any information about the slowness? Is it in the
database or outside?

Kind regards

robert

 

[Ralph Shnelvar]

Wednesday, November 25, 2009, 10:35:06 AM, you wrote:

Ralph Shnelvar wrote:
[...]

RK> ? Btw, having columns with indexes in their name is considered bad
RK> schema design because you either could normalize it into another
table
RK> and join or provide more meaningful names instead of "x02" if it is
used
RK> as a placeholder. My 0.02EUR.

RK> Kind regards

First of all, I'm a noob. I should have said that.

Thus your solution
(1) Makes sense.
(2) Explains a lot about Ruby.

For both I thank you.


In terms of normalizing the database, I ran some timing tests and
normalizing it slows me down a couple of orders of magnitude. I'm
willing to live with the lack of purity for the sake of performance.

A couple orders of magnitude? This suggests to me that your
normalization and/or queries are poorly done. What is chewing up so
much time, and what does the normalized schema look like? It should be
possible to find a solution that performs reasonably and doesn't have 20
repeating fields.

RK> I second that. Ralph, any information about the slowness? Is it in the
RK> database or outside?

I _think_ it is, in part, coming from the logging that is being done.

Instead of one create ... one can have 21.

 

[Marnen Laibow-Koser]

Wednesday, November 25, 2009, 10:35:06 AM, you wrote:



RK> I second that. Ralph, any information about the slowness? Is it in
the
RK> database or outside?

I _think_ it is, in part, coming from the logging that is being done.

Instead of one create ... one can have 21.

Then, as I suspected, you are using the DB incorrectly. To create 21
records, use 1 query, not 21. You can use ar-extensions or something
similar to do this with ActiveRecord.

Rule of thumb: queries don't belong inside loops. If you find yourself
putting a query in a loop, you have a design problem.

Best,