Rails - May 2006 - Is Rails a good place to start for a newb to the database

Is Rails a good place to start for a newb to the database world ??

I need to make a database that is searchable with multiple filters that 
can be turned on and off at a moments notice kinda like java xhtml 
dynamic loading..

I have not worked with php or mysql much more than basic scripts running 
and website defaults. so I am new to the racket and want to pick 
something that is robust and fast to implement and learn...

If so , what would be a good book to snag from the book store ??

-- 
Posted via http://www.ruby-forum.com/.

Rails is a great place to start. First, I would advise that you make or
watch a tuto. Then, you make some experiments. Then, if you decide to go
with rails, you should consider buying the very affordable book agile
development with rails:
http://pragmaticprogrammer.com/titles/rails/index.html

Some excellent tutos and the webcasts are listed at
http://www.rubyonrails.org/docs

Regards,

Nicolas


On 5/30/06, trip dragon <colo0logo@gmail.com>
wrote:
>
> Is Rails a good place to start for a newb to the database world ??
>
> I need to make a database that is searchable with multiple filters that
> can be turned on and off at a moments notice kinda like java xhtml
> dynamic loading..
>
> I have not worked with php or mysql much more than basic scripts running
> and website defaults. so I am new to the racket and want to pick
> something that is robust and fast to implement and learn...
>
> If so , what would be a good book to snag from the book store ??
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060530/48980f03/attachment.html

I think Rails is a great place to start with web development - it kicks 
you off some great ''best practices'' that most of us take years
to come
to :0)  It''s also very easy to get started, but at the same time 
powerful enough to keep up as your abilities and needs grow.

In terms of databases, Rails abstracts the database to a certain degree 
but it also ''encourages'' good data modeling.  You''ll
pick up a lot of
good database design practices as you learn Rails.

As for books, the ''Agile'' book comes highly recommended: 
http://www.pragmaticprogrammer.com/titles/rails/index.html.  The 1st 
edition is in the shops but if you can, i''d get the PDF version as
it''s
more up-to-date.  Plus, you''ll get updates for free :0)

Best thing to do is get the book, download rails and start playing - 
you''ll suprised how easy it all is :0)

Steve


trip dragon wrote:
> Is Rails a good place to start for a newb to the database world ??
> 
> I need to make a database that is searchable with multiple filters that 
> can be turned on and off at a moments notice kinda like java xhtml 
> dynamic loading..
> 
> I have not worked with php or mysql much more than basic scripts running 
> and website defaults. so I am new to the racket and want to pick 
> something that is robust and fast to implement and learn...
> 
> If so , what would be a good book to snag from the book store ??
>

Stephen Bartholomew wrote:
> 
> In terms of databases, Rails abstracts the database to a certain degree
> but it also ''encourages'' good data modeling. 
You''ll pick up a lot of
> good database design practices as you learn Rails.
> 
I don''t think so.
Rails encourages to use some common bad practices, which are wide-spread 
in providing access to SQL-DBMS from OOP languages.
Good data modeling is a general off-Rails topic, go and read some 
C.J.Date''s books :)

-- 
Posted via http://www.ruby-forum.com/.

> I don''t think so.
> Rails encourages to use some common bad practices, which are wide-spread 
> in providing access to SQL-DBMS from OOP languages.
> Good data modeling is a general off-Rails topic, go and read some 
> C.J.Date''s books :)
> 

Can you describe some of these bad practices?

Charlie Bowman    
Programmer
Castle Branch Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060530/f4415c81/attachment-0001.html

Well i think you could say that''s a matter of context and taste.  Sure,
as a top-boy DBM you''d probably cry at some of the things that are done
in Rails apps.  I have a background in quite rigid database design and 
when i started Rails i did sometimes think ''yeah but shouldn''t
i be
doing this or that?''  At the end of the day, most of it didn''t
matter in
the context of pretty much every web app i write.

Rails encourages sensible naming conventions, normalization and correct 
relationship management - what more do you need in a web app? :0)

Steve

dseverin wrote:
> Stephen Bartholomew wrote:
> 
>>In terms of databases, Rails abstracts the database to a certain degree
>>but it also ''encourages'' good data modeling. 
You''ll pick up a lot of
>>good database design practices as you learn Rails.
>>
> 
> 
> I don''t think so.
> Rails encourages to use some common bad practices, which are wide-spread 
> in providing access to SQL-DBMS from OOP languages.
> Good data modeling is a general off-Rails topic, go and read some 
> C.J.Date''s books :)
>

Charlie Bowman wrote:
>> I don''t think so.
>> Rails encourages to use some common bad practices, which are
wide-spread
>> in providing access to SQL-DBMS from OOP languages.
> 
> Can you describe some of these bad practices?
> 
Ok, this is Rails way for DB conventions, to name a few:
1) autoinc ID column for tables
2) STI for model class inheritance (IMHO, table inheritance is, uhm, not 
a good thing at all, and STI is damn ugly workaround for speed)
3) no composite keys
4) put all constraints(validations, foreign keys, triggers) in 
application (ruby code in ActiveRecord descendants), and none in 
database  schema (except, maybe, column types :) )

Sure, I can be totally dumb, but sticking from the newb start with such 
a conventions can lead later to major headaches in more complex apps 
than 15-minute blog :)
There are reasons when to follow these conventions would be good, but 
there are also reasons when you just *must avoid* such practices.
The knowledge to choose the right solution (which may contradict 
someone''s opinion ) is totally off Rails.

P.S. I can''t remember, if all design desicions made by DHH for 
ActiveRecord have ever been summarized, though partially discussed 
several times over the net.

-- 
Posted via http://www.ruby-forum.com/.

> Ok, this is Rails way for DB conventions, to name a few:
> 1) autoinc ID column for tables
What''s wrong with this?  I was using this way before I started using
rails?

> 2) STI for model class inheritance (IMHO, table inheritance is, uhm, not 
> a good thing at all, and STI is damn ugly workaround for speed)
I have never used this once in the 30+ web apps I''ve created.
> 3) no composite keys
Your are correct.  This is truely needed if we are going to be able to
use rails with legacy databases!
> 4) put all constraints(validations, foreign keys, triggers) in 
> application (ruby code in ActiveRecord descendants), and none in 
I''m not convinced that triggers are a good thing when stored in the
database.  It forces the programmer to remember what happens for certain
events.  It also forces them into using another programming language.  I
truly love having these "triggers" in the application.

Charlie Bowman
http://www.recentrambles.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060530/a9a4df88/attachment-0001.html

Most of this is probably not as important as you think it is.  Yeah, 
constraints are in the application - but why is that a problem?  If it 
*is* a problem, you can always add those constraints in the db yourself 
- like you would in any other app.  I can''t think why the id column is
a
problem - and again, if you''re crazy, you can override that too.

Anyway - this has all been hashed out before :0)

At the end of the day, there are a lot of developers out there who have 
developed web applications for years and are happy with the conventions 
set in Rails.  Sure there are things to be improved on, but i personally 
like the way things are and the way they''re going.

As such a shall continue to recommend Rails and it''s conventions :0)

Steve




dseverin wrote:
> Charlie Bowman wrote:
> 
>>>I don''t think so.
>>>Rails encourages to use some common bad practices, which are
wide-spread
>>>in providing access to SQL-DBMS from OOP languages.
>>
>>Can you describe some of these bad practices?
>>
> 
> 
> Ok, this is Rails way for DB conventions, to name a few:
> 1) autoinc ID column for tables
> 2) STI for model class inheritance (IMHO, table inheritance is, uhm, not 
> a good thing at all, and STI is damn ugly workaround for speed)
> 3) no composite keys
> 4) put all constraints(validations, foreign keys, triggers) in 
> application (ruby code in ActiveRecord descendants), and none in 
> database  schema (except, maybe, column types :) )
> 
> Sure, I can be totally dumb, but sticking from the newb start with such 
> a conventions can lead later to major headaches in more complex apps 
> than 15-minute blog :)
> There are reasons when to follow these conventions would be good, but 
> there are also reasons when you just *must avoid* such practices.
> The knowledge to choose the right solution (which may contradict 
> someone''s opinion ) is totally off Rails.
> 
> P.S. I can''t remember, if all design desicions made by DHH for 
> ActiveRecord have ever been summarized, though partially discussed 
> several times over the net.
>

>> 2) STI for model class inheritance (IMHO, table inheritance is, uhm,
not
>> a good thing at all, and STI is damn ugly workaround for speed)
> 
> I have never used this once in the 30+ web apps I''ve created.
> 
And it''s not as if DHH just pulled STI as the default out of thin air:

http://wrath.rubyonrails.org/pipermail/rails/2004-December/000839.html


-- 
Posted via http://www.ruby-forum.com/.

Hmm.. Well my focus is an upgrade from Filemaker.. Since it has hit one 
to many bottle necks for me in it''s weird design.. Plus I like clean 
code whenever I can get it..

I will watch some tutorials and see what comes of it.. Thank you all :D

-- 
Posted via http://www.ruby-forum.com/.

Charlie Bowman wrote:
>> Ok, this is Rails way for DB conventions, to name a few:
>> 1) autoinc ID column for tables
> 
> What''s wrong with this?  I was using this way before I started
using
> rails?
> 
It becomes very wrong if all your tables have such a primary key for 
only reason -- it is by Rails convention :)
> 
>> 4) put all constraints(validations, foreign keys, triggers) in 
>> application (ruby code in ActiveRecord descendants), and none in 
> 
> I''m not convinced that triggers are a good thing when stored in
the
> database.  It forces the programmer to remember what happens for certain
> events.  It also forces them into using another programming language.  I
> truly love having these "triggers" in the application.
> 
Hm, writing an app that talks to RDBMS w/o any knowledge of SQL and 
procedural SQL extension for your production database server? Are you 
kidding? Developers inevitably must know this "another language" well,
it is like requirement to be familiar with XHTML, CSS, JS, XML/XSLT etc. 
in web development ( besides, e.g in Postgres you can write stored proc 
and triggers in PL/Ruby :) ).
And after all I don''t see much logical difference between "CREATE 
TRIGGER ... AFTER UPDATE ON A ..." and "class A <
ActiveRecord::Base;
def after_save; ... end ; end"

To make a summary: Rails conventions are best suited for Rails framework 
and allow you to make common tasks in no time.

They aren''t really that bad, but blindly making them your habits is 
unacceptable. That''s what I consider bad, so don''t recommend
them as
*good database practices*

P.S. sorry for flooding :)
P.S. sorry for flooding :)

-- 
Posted via http://www.ruby-forum.com/.

When asked for a good place to start, try to focus on what the person asking
knows: not much. My opinon is that rails ensures excellent practices,
especially auto inc and constraints in the code. You can start straight
away, and learn within a few hours because the setup of the environment is
lighting fast.

When you become fluent, you improve, read, and start having your own
opinion. But I think it''s much better to strat with a solid framework
that
ensures at least some excellent (you would say honorable) practices, than
with a .net framework that will leave you wondering what the hell is going
on with you ado connection, why you cannot connect with firefox, and why
your data table tkaes 20 min to display.

Now, if you''re talking about engineering the backend server of
citybank,
Rails practices are certainely aguables. But it''s not where one should
start
;)

On 5/30/06, Stephen Bartholomew <sb@2404.co.uk>
wrote:
>
> Most of this is probably not as important as you think it is.  Yeah,
> constraints are in the application - but why is that a problem?  If it
> *is* a problem, you can always add those constraints in the db yourself
> - like you would in any other app.  I can''t think why the id
column is a
> problem - and again, if you''re crazy, you can override that too.
>
> Anyway - this has all been hashed out before :0)
>
> At the end of the day, there are a lot of developers out there who have
> developed web applications for years and are happy with the conventions
> set in Rails.  Sure there are things to be improved on, but i personally
> like the way things are and the way they''re going.
>
> As such a shall continue to recommend Rails and it''s conventions
:0)
>
> Steve
>
>
>
>
> dseverin wrote:
> > Charlie Bowman wrote:
> >
> >>>I don''t think so.
> >>>Rails encourages to use some common bad practices, which are
> wide-spread
> >>>in providing access to SQL-DBMS from OOP languages.
> >>
> >>Can you describe some of these bad practices?
> >>
> >
> >
> > Ok, this is Rails way for DB conventions, to name a few:
> > 1) autoinc ID column for tables
> > 2) STI for model class inheritance (IMHO, table inheritance is, uhm,
not
> > a good thing at all, and STI is damn ugly workaround for speed)
> > 3) no composite keys
> > 4) put all constraints(validations, foreign keys, triggers) in
> > application (ruby code in ActiveRecord descendants), and none in
> > database  schema (except, maybe, column types :) )
> >
> > Sure, I can be totally dumb, but sticking from the newb start with
such
> > a conventions can lead later to major headaches in more complex apps
> > than 15-minute blog :)
> > There are reasons when to follow these conventions would be good, but
> > there are also reasons when you just *must avoid* such practices.
> > The knowledge to choose the right solution (which may contradict
> > someone''s opinion ) is totally off Rails.
> >
> > P.S. I can''t remember, if all design desicions made by DHH
for
> > ActiveRecord have ever been summarized, though partially discussed
> > several times over the net.
> >
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060530/d1e84113/attachment.html

trip dragon wrote:
> Is Rails a good place to start for a newb to the database world ??
> 
> I need to make a database that is searchable with multiple filters that 
> can be turned on and off at a moments notice kinda like java xhtml 
> dynamic loading..
> 
> I have not worked with php or mysql much more than basic scripts running 
> and website defaults. so I am new to the racket and want to pick 
> something that is robust and fast to implement and learn...
> 
> If so , what would be a good book to snag from the book store ??
Yes I think it''s an excellent place to start.  Learning Rails was my 
first foray into MySQL, but I''ve got my second app up and running using
the sometimes feared has_and_belongs_to_many associations (don''t worry 
about knowing that yet).

I''d programmed before, but mostly in actionscript and javascript, and 
hadn''t touched any lines of SQL.  I think what makes Rails good for a 
noob is that you can get something worthwhile up and running and then 
examine it from the top down.  For me anyway this worked out to be a 
better learning method than starting with ''hello world'' in
other
languages I tried and got frustrated with slow progress.

Don''t get me wrong, sometimes I''ve wanted to bang my head
against a wall
using rails too.  Once I got off the scaffolds it wasn''t such a bright 
picture.  But slowly and more patiently I am learning enough that I feel 
I can take on more with every app.

These people sure help, and so do the ones on IRC.

Jason
http://www.pfosphene.com


-- 
Posted via http://www.ruby-forum.com/.

> >> 4) put all constraints(validations, foreign keys, triggers) in 
> >> application (ruby code in ActiveRecord descendants), and none in 
> > 
> > I''m not convinced that triggers are a good thing when stored
in the
> > database.  It forces the programmer to remember what happens for
certain
> > events.  It also forces them into using another programming language. 
I
> > truly love having these "triggers" in the application.
> > 
> 
> Hm, writing an app that talks to RDBMS w/o any knowledge of SQL and 
> procedural SQL extension for your production database server? Are you 
> kidding?  
Everyone knows that a developer must know SQL to be decent at what they
do.  That wasn''t what I was implying and it wasn''t what I
said.  I have
never used a trigger or stored procedure, and I have never seen a time
when it would have been beneficial for me either.  Setting constraints
in your database is good at the individual field level.  I think the
database should do only what it''s best at...retrieving and storing
data.
Writing code the database to use seems a little weird to me.  Maybe
that''s because I''ve always used MySql.  It''s just my
personal
preference.  I see that you disagree with me on that.  I think most of
the world is also divided on the issue.  


Charlie Bowman    
Programmer
Castle Branch Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060530/f9dfa560/attachment.html

On 5/30/06, dseverin <dmitry.severin@gmail.com> wrote:
> It becomes very wrong if all your tables have such a primary key for
> only reason -- it is by Rails convention :)
Every table should have a single, primary key that has no intelligible
context.  It may not be "convention", but it''s experience. 
;)  When
you have to rearchitect a many million-line VFP application because
SSN was not allowed anymore (it was the primary key in many user
tables) you will understand.  Save yourself time and your clients
money.

Just because the scientists and authors say it, doesn''t mean it is
so...

> Every table should have a single, primary key that has no intelligible
> context.  It may not be "convention", but it''s
experience.  ;)
<...>

+1.
Except for join tables. Maybe.

Regards,
Rimantas
--
http://rimantas.com/