Sei não, uma coisa que não se resolve com cache só pode ser query mal feita.[/quote]
Query mal feita é o que mais existe. Complicado é achar uma bem feita, claro nao estou falando de “SELECT * FROM TABELA” e sim de SQL complexo.
Pode ter certeza que uma query mal feita no JDBC puro é muito menos custosa que uma feita via HQL por exemplo mesmo com o cache.
Mas nao é neste caso que eu quiz dizer que os caches nao sao a salvacao, mas sim em estruturas de dados (tabelas) muito complexas com tabelas que desencadeiam mais de 500 tabelas filhas, ai sim é um grande problema, que tem que ter cache, querys bem feitas, tuning de banco e mais umas consinhas pra se conseguir algo descente.
[quote=Maurício Linhares]Ah CV, mas e se o DBA for fresco e não quiser que seja assim?
Eu to participando de um curso aqui que todas as tabelas que o cara tá mostrando, são tb_nome_da_tabela, as views são vw_nome_da_view. Quando só tem a aplicação dagente acessando, isso é besteira, mas e quando outras aplicações também acessam com esses nomes horríveis?
Aí num dá pra mudar :?
Ah, outra coisa, como é que faz N:N no AR CV? Eu só vi até 1:N (você já pegou aquele livro de Rails? Da Pragmatic?)[/quote]
Grande parte da magica que o Rails faz eh baseada em convencoes de nomenclatura, tanto no banco de dados quanto no codigo em Ruby. Se vc quiser fugir do padrao, ok, mas vc vai ter que configurar um monte de coisas. Eh chato, BEM MAIS chato, mas ainda da pra usar, mas eh bem melhor peitar o DBA, afinal as convencoes do Rails sao bem inteligentes.
Mapeamento N:N “nao existe”. Voce sempre acaba usando uma join table no fim das contas, entao pq nao dar um nome significativo a essa tabela e ficar com um 1:N e outro N:1?
