Modelagem de BD, RoR & Migrations ou Ferramentas CASE?

[Gedean]

Olá!

Gostaria de saber de quem veio, ou ainda continua trabalhando, com
aplicações desktop principalmente com linguagens como C/C++ e Delphi,
se adotaram o modo RoR de desenvolvimento, gerando o BD a partir do
mecanismo de Migrations ou fazem como antes, modelam o banco de dados
primeiro em uma ferramenta CASE para depois linkar aos Models.

Contem suas experiências.

Atenciosamente,

Gedean Dias

[Diego Lucena]

Ola Gedean, no inicio eu modelava em alguma ferramenta de case e depois dentro do rails criava as migrations, nunca cheguei a fazer direto no banco de dados sem usar as migrations do rails, mas eu nao criava uma migration para cada alteração, eu alterava as migrations existentes (gerada por script scaffold). Mas Agora faço no rails way, ou seja, vou criando migrations para as alterações, correções, novos models,  etc, e modelo o bd com papel e lapis mesmo, devo confessar que é bem mais simples trabalhar assim. Então sugiro que experimente trabalhar só com migrations, o que é interessantes principalmente para facilitar o deploy e manter o estado do banco de dados atual correto para o código do programa, interessante quando mais de um programador esta trabalhando na aplicação. Sugiro que assista o episódio 83 do railscast fala bem sobre migrations.

Espero ter ajudado.

att.

Diego

2009/11/3 Gedean <gedea...@gmail.com>

[Igor Leroy]

Concordo com o Diego, ainda trabalho com .NET e sempre usamos ferramentas CASE, no entanto em meus projetos Rails so utilizo as migrations. Vale muito mais a pena.

2009/11/3 Diego Lucena <diegoj...@gmail.com>

--
-- Igor Leroy
-- Desenvolvedor Web
-- www.igorleroy.com

[Gedean]

Obrigado pelas respostas! Acho que estou mesmo com o mind-set errado,
muito atrelado ao desktop, afinal com outra tecnologia, temos que
trabalhar de acordo com o que ela preconiza ...

Eu fico indagando também sobre questões como integridade referencial,
otimização de índices, etc.

Outra coisa, é que eu gosto do modo como nomeava os objetos do banco
de dados: tb_nome_tabela, vw_nome_tabela, com o Rails é outra
convenção, o nome do Objeto do código pluralizado. No fundo, é o que
mais me incomoda nessa transição de teconologia.

Atenciosamente,

Gedean Dias

[wurtog]

Gedean,

A nomeclatura do Rails não é exigência. Pode continuar a usar sua
nomeclatura antiga, vide:

http://apidock.com/rails/ActiveRecord/Base/set_table_name/class

Abraços!

2009/11/3 Gedean <gedea...@gmail.com>:

--
wurtog
http://twitter.com/wurtog

[Igor Leroy]

Exatamente e tambem nada te impede de fazer relacionamento, integridade e otimização em indices.
Basta seguir as regras do Active Record.

2009/11/3 wurtog <wur...@gmail.com>

[Gedean]

Obrigado novamente!

Bem, sei que dá pra usar a antiga nomeclatura, mas fica parecendo uma
coisa fora de lugar ... desalinhado com o jeito RoR.

Eu trabalho com consultoria em um segmento muito específico de
governo, uso conhecimentos em programação para desenvolver ferramentas
para meu uso próprio, venho testando Ruby e Ruby On Rails em cima das
bases pré-existentes, mas agora, como vêm surgindo necessidades de
novas ferramentas, sinto vontade de implementá-las com o RoR, mas
ainda não sinto segurança, até porque existe um conjunto enorme de
outras capacidades que devo desenvolver para projetos web, ex.: Web
Standards, HTML, CSS, AJAX, Servidores, hospedagem, deploy, etc. ou
seja, todo o eco-sistema exigido para uma aplicação WEB, apesar de a
curva de aprendizado de algumas ser bastante tênue. E em adição a
isso, novas práticas no desenvolvimento da aplicação ... praticamente
só se aproveita os conhecimentos do negócio e de Orientação à Objetos.

[MarcRic]

Gedean e demais participantes da thread.

Vai aqui, como o Gedean solicitou a minha experiência relativamente
recente (tive esta discussão num grupo de aprendizado que participei a
cerca de um ano).

Como tenho muita experiência em TI (eufemismo pra "tô ficando velho"),
e tenho raízes muito fortes em DB relacionais (já dei aula, fui DBA, e
sempre desenvolvi orientado a modelagem de banco primeiro), quando
comecei a aprender Rails, questionei MUITO as "opiniões",
principalmente em relação a implementar relacionamentos fora do banco,
pois tenho problemas sérios numa aplicação VB desktop até hoje por
conta da falta de integridade referencial no banco.

Outra questão que eu questionei muito foi a da performance (criação e
administração de índices).

Vamos ao que concluímos lá neste grupo de estudo:

1 - Rails é ideal para aplicações novas. Dá pra adaptar aplicações
legadas? Dá, mas vai dar bastante trabalho.
2 - Quanto à ferramentas CASE, já tinha parado de usar a algum tempo.
Como eles mudavam toda hora lá no trabalho e variam também de cliente
para cliente, prefiro fazer o design no papel, como o colega já citou,
documentar muito bem no banco (comentários para tabelas, colunas, e se
o banco permitir para os demais objetos), e depois usar a ferramenta
CASE da ocasião aplicando engenharia reversa no banco.
3 - A questão do plural no nome das tabelas, é uma simples questão de
convenção, e existem adeptos das duas possibilidades: CUSTOMER ou
CUSTOMERS, qual é a melhor? No plural porque a tabela armazena
instâncias daquele objeto, ou no singular porque a tabela representa a
classe dos objetos? Eu, até então sempre usava no singular, mas
preferi me adaptar ao Rails do que ter mais trabalho (Eehh
preguiça...), mas como já disseram dá pra fazer do outro jeito.
4 - Tudo que for complementar (do seu gosto pessoal) dá pra criar
scripts específicos no migrations e fazer o que você quiser, até de
forma explícita (comandos SQL diretos), para, por exemplo, colocar
comentários no banco, criar índices, etc.).
5 - Procure pensar TODA a solução, incluindo o banco de dados, em
Inglês, depois use as facilidades de "internacionalização" para
"nacionalizar" (essa foi boa... he he...). Dá menos trabalho e a
solução já fica "universal".

Espero ter ajudado.

Grande abraço.

[Igor Leroy]

MarcRic,
Já que é experiente na area, poderia responder a duvida de um relativamente novato?
O modo Rails de mapear o banco, torna a aplicação lenta? Ja que não tem indices, relacionamentos e etc. As vezes é dificil convencer um xiita em .NET ou Java que Rails é diferente, mas não lento.

2009/11/4 MarcRic <mar...@gmail.com>

[Ivan H. Schuster]

Igor, se não te preocupares com indexação o teu SGBD vai para o buraco. Vai atolar a tua máquina.
Não tem mágica em acesso a SGBD-R. Tem que indexar corretamente.
O Rails oferece bom suporte a indexação através das Migrations.
Sugiro que dês uma lida a respeito.

Abs,

Igor Leroy escreveu:

-- 
Ivan Holsbach Schuster

[Marcelo Castellani]

Oi Igor

Rails tem tudo isso.

Marcelo

[Rodrigo Manhães]

Caros,

inicialmente desculpem se estou desviando o tópico.

As migrations do Rails oferecem um modo de se evoluir uma aplicação de
modo iterativo-incremental [1]. Provavelmente, encorajar um ciclo de
vida iterativo-incremental é mais uma das "opiniões" do Rails, opinião
aliás muito bem vinda. Do modo que é, o mecanismo de migrations
desencoraja - mas de modo algum impede - que se realize big design up
front [2], o que também é ótimo. Enfim, já que se falou em mindset na
thread, na mudança para o Rails pode ser interessante que se repense
também o modo como a atividade de desenvolver software é encarada.
Estou falando de desenvolvimento ágil de software [3], para o qual o
Rails, sua comunidade e seu ecossistema caem como uma luva. Foi este,
aliás, o principal motivo de minha mudança de Java/JSF para Ruby/Rails
como principal plataforma de desenvolvimento, no primeiro semestre
deste ano.

[]'s
Rodrigo

[1] O livro Agile Web Development with Rails, escrito pelo Dave Thomas
(signatário do manifesto ágil [4]) e David Hansson (o pai da criança),
traz um exemplo de criação de uma aplicação exatamente deste modo.
[2] http://www.agilemodeling.com/essays/bmuf.htm
[3] http://www.improveit.com.br/xp
[4] http://agilemanifesto.org



2009/11/4 Marcelo Castellani <mar...@hypequino.com>:

[Aldemir Vieira]

Falando nisso, alguém usa o Liquibase ou software similar para Rails?

http://www.liquibase.org/

2009/11/4 Rodrigo Manhães <rman...@gmail.com>

--
Forte abraço,
Aldemir Vieira

[MarcRic]

Igor,

Respondendo a você e englobando partes do que já foi dito desde a sua
pergunta.

Não há mágica em relação ao banco, você precisa SIM, se preocupar com
a criação de índices, e pode, se julgar conveniente, e dependendo do
RDB utilizado, criar objetos de apoio como constraints por exemplo,
tudo usando o recurso padrão de migrations, e de forma mais ou menos
explícita. Vão existir comandos específicos para um determinado RDB,
que não são mapeados por nenhum ORM como o active record por exemplo.
Daí você pode usar até comandos SQL explícitos, mas mantendo o uso das
migrations.

O que o Rails proporciona através das migrations (como também já foi
dito), é uma maneira de ir evoluindo e documentando todo o processo,
sem ter que se preocupar com todos os possíveis relacionamentos e os
possíveis filtros desde o início, o que, cá entre nós, se não é
impossível, é desaconselhável, pois vai levar o seu projeto para o
modelo waterfall, afastando-o do modelo ágil de sprints curtos com
entrega de valor para o cliente.

Como o Rodrigo falou, quando você passa a desenvolver em Ruby on
Rails, é uma boa hora para mudar a forma de conduzir os seus projetos,
se não no trabalho (as vezes isto não é possível), ao menos, nos seus
projetos particulares.

Grande abraço.

P.S. Sou experiente sim, na área de TI (mais de 30 anos), em Web em
geral, tô estudando e aprendendo a cerca de 4 anos apenas, Ruby,
comecei no final de 2007, e Rails em meados de 2008. E tem é coisa pra
aprender hein...

Aprender é ótimo.

On 4 nov, 20:42, Igor Leroy <ip.le...@gmail.com> wrote:
> MarcRic,
> Já que é experiente na area, poderia responder a duvida de um relativamente
> novato?
> O modo Rails de mapear o banco, torna a aplicação lenta? Ja que não tem
> indices, relacionamentos e etc. As vezes é dificil convencer um xiita em
> .NET ou Java que Rails é diferente, mas não lento.
>

> 2009/11/4 MarcRic <marc...@gmail.com>

[Igor Leroy]

MarcRic,

Obrigado pelas dicas. Geralmente que se vê em blogs ou pela net, da a entender que desenvolvedores Rails não ligam muito para o comportamento do banco, achando que o Active Record ja faz tudo. Pelo jeito me enganei e muito.
Estou no mundo Ruby ha menos de um ano, ainda tenho MUITO a aprender.

2009/11/5 MarcRic <mar...@gmail.com>