Forum: Ruby on Rails Is Rails a good place to start for a newb to the database

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
B4e37f0a961cef360290869d5ef2b5bf?d=identicon&s=25 Trip Dragon (tripdragon)
on 2006-05-30 16:33
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 ??
C29d9db03853958c4de5ee6b06edd39a?d=identicon&s=25 Nicolas Buet (Guest)
on 2006-05-30 16:45
(Received via mailing list)
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
882cc23c77c5c6d27613c51396a02a0d?d=identicon&s=25 Stephen Bartholomew (Guest)
on 2006-05-30 16:48
(Received via mailing list)
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
D57f4a4788599a38494865a121f16bbe?d=identicon&s=25 dseverin (Guest)
on 2006-05-30 16:56
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 :)
89d967359903c639d31e4cad4569f537?d=identicon&s=25 Charlie Bowman (Guest)
on 2006-05-30 17:06
(Received via mailing list)
> 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.
882cc23c77c5c6d27613c51396a02a0d?d=identicon&s=25 Stephen Bartholomew (Guest)
on 2006-05-30 17:13
(Received via mailing list)
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
D57f4a4788599a38494865a121f16bbe?d=identicon&s=25 dseverin (Guest)
on 2006-05-30 17:25
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.
89d967359903c639d31e4cad4569f537?d=identicon&s=25 Charlie Bowman (Guest)
on 2006-05-30 17:40
(Received via mailing list)
> 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
882cc23c77c5c6d27613c51396a02a0d?d=identicon&s=25 Stephen Bartholomew (Guest)
on 2006-05-30 17:47
(Received via mailing list)
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
Db2175eb86669d396b8596d11478f5ef?d=identicon&s=25 Cayce Balara (yardboy)
on 2006-05-30 17:56
>> 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-...
B4e37f0a961cef360290869d5ef2b5bf?d=identicon&s=25 Trip Dragon (tripdragon)
on 2006-05-30 17:58
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
D57f4a4788599a38494865a121f16bbe?d=identicon&s=25 dseverin (Guest)
on 2006-05-30 18:01
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 :)
C29d9db03853958c4de5ee6b06edd39a?d=identicon&s=25 Nicolas Buet (Guest)
on 2006-05-30 18:15
(Received via mailing list)
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
;)
E25296bf52723dc37bc462271eb02d2d?d=identicon&s=25 Jason Pfeifer (jpfeifer)
on 2006-05-30 18:38
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
89d967359903c639d31e4cad4569f537?d=identicon&s=25 Charlie Bowman (Guest)
on 2006-05-30 19:33
(Received via mailing list)
> 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.
39c5254d0a798765f37ac215fa6e0fc7?d=identicon&s=25 Curtis Spendlove (cuspendlove)
on 2006-05-30 20:10
(Received via mailing list)
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...
Ec5a599777854c540fd102ef4691fe10?d=identicon&s=25 Rimantas Liubertas (Guest)
on 2006-05-30 20:13
(Received via mailing list)
> 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/
This topic is locked and can not be replied to.