Construindo uma Rede Social

[André Manoel 2]

Pessoal,

 

Vou dar aqui as minhas sugestões baseados no andamento do projeto.

 

A necessidade de padronização de código é muito importante. Em questão de escrita, declaração de métodos, classes e tudo mais.

 

Vocês não estariam dispostos a utilizar neste desafio o Zend Framework?

O único framework desenvolvido pela empresa que "toma conta do PHP"?

 

Eu tenho trabalhado com ele, e vou lhes dizer... nunca produzi tanto como agora com este framework PHP.

Ele é muito bom! Muito rápido!

Ele tem uma estrutura MVC muito bem estruturada.

E tem um padrão de desenvolvimento que vai nos permitir o desenvolvimento modular e com o mesmo padrão de nomenclatura.

Tem suporte a muitas coisas que teríamos que desenvolver na mão. Não precisaríamos reinventar a roda.

Já que grande parte dos problemas com MVC, e diversos Design Patterns já estão codificados dentro dele.

E ele também tem uma parte de persistência(Operações com banco de dados), incrível.

Se estivermos desenvolvendo com o MySQL e resolvermos mudar para Cassandra, Oracle, SQLServer, PostGree ou qualquer outro banco,

Só precisaríamos mudar 3 linhas no código e tudo estaria funcionando perfeitamente.

Podemos integrá-lo com o EXTJs...

 

Iríamos nos preocupar com as novidades do projeto.

 

E além disso todos teriam a oportunidade de desenvolver com este framework que está sendo muito utilizado no mercado de trabalho.

Pelo menos em Brasília aonde moro.

 

Aplicações gigantescas... e aplicações pequenas, websites e tudo o que tem desenvolvimento web aqui estão usando o Zend Framework.

 

Seria uma ótima oportunidade de todos aprenderem este framework.

Estou aqui disponível para passar o passo a passo de como utilizar o framework.

 

Vocês acham que não é mesmo viável utilizar este framework de PHP?

[Guustavo0 0]

Bom queria ajudar em todas as areas, entendo um pouco de cada, e como estou no começo da minha historia como programador seria uma otima oportunidade para mim aprender coisas novas :D

[pslucasps 2]

Pra ser sincero, o projeto basicamente está se limitando a aquilo que aqui em são paulo denominamos "molho". pessoas quais eu indiquei este projeto, amigos de msn, deviantart, etc, com certeza não aguentaram o nível do preposto já que são iniciantes e ainda não desenvolveram ritmo de trabalho e facilidade de aprendizado.

 

Voltando novamente nessa questão penso diferente. Acredito que em sua visão (baseando-se pelos seus posts) você vê que o objetivo desse projeto é construir uma rede social onde quem sabe faz e quem não sabe olha para aprender. Na minha opinião essa é justamente a ideia oposta colocada pelo João. Para mim o objetivo é dividir conhecimento para construir uma rede social. Nesse caso a rede social seria apenas uma forma de praticar e aplicar o conhecimento onde todos participariam.

 

Achei a ideia fantástica e voltando ao assunto do tópico, quanto a escolha das ferramentas penso que o melhor é realizar essas escolhas pensando nas tecnologias mais difundidas uma vez que isso facilita o aprendizado e traz mais pessoas para o projeto. No caso do Jquery e do ExtJS comentado anteriormente por exemplo, escolheria-se a tecnologia mais difundida.

[Untill 0]

 

Pra ser sincero, o projeto basicamente está se limitando a aquilo que aqui em são paulo denominamos "molho". pessoas quais eu indiquei este projeto, amigos de msn, deviantart, etc, com certeza não aguentaram o nível do preposto já que são iniciantes e ainda não desenvolveram ritmo de trabalho e facilidade de aprendizado.

 

Voltando novamente nessa questão penso diferente. Acredito que em sua visão (baseando-se pelos seus posts) você vê que o objetivo desse projeto é construir uma rede social onde quem sabe faz e quem não sabe olha para aprender. Na minha opinião essa é justamente a ideia oposta colocada pelo João. Para mim o objetivo é dividir conhecimento para construir uma rede social. Nesse caso a rede social seria apenas uma forma de praticar e aplicar o conhecimento onde todos participariam.

 

Achei a ideia fantástica e voltando ao assunto do tópico, quanto a escolha das ferramentas penso que o melhor é realizar essas escolhas pensando nas tecnologias mais difundidas uma vez que isso facilita o aprendizado e traz mais pessoas para o projeto. No caso do Jquery e do ExtJS comentado anteriormente por exemplo, escolheria-se a tecnologia mais difundida.

 

Você obviamente não leu todos os posts né?

[pslucasps 2]

Você obviamente não leu todos os posts né?

 

Li sim, desde o inicio, assim como li todos os posts dos outros tópicos referente a esse asunto.

[Rogério Y. 0]

gostaria de participar do PHP...

 

se precisarem... estou aqui.

[Duardaum 0]

Sou WebMaster PHP e DBA. Caso forem criar essa rede social, gostaria de ajudar na criação do banco de dados.

 

Se precisarem..

 

To aqui..

[angelorubin 142]

Bom dia Pessoal,

 

Primeiramente parabenizar o pessoal que "encabeçou" a idéia da rede social, achei fantástica.

 

Eu ri muito com a escolha dos nomes foi inevitavel.

 

E o nome escolhido TYFU é sensacional, nada mais sugestivo !

 

Imaginem só as piadinhas !

 

Bom, mas voltando ao foco e falando sério estou a disposição para ajudar no que se refere a LAYOUT/XHTML/CSS.

[Evandro Oliveira 331]

Posso encabeçar o front-end (x)html/css se mais ninguém da área estiver disposto.

 

Farei a "distribuição de tarefas" e revisão dos trabalhos além, claro, de dar a minha partezinha de marcação. Me disponho à orientação e debate sobre semântica na marcação e alternativas com CSS. Mas resumo a tarefa por aqui para não misturar muito com o foco do tópico. Como dito, se mais ninguém desejar o "posto", crio o Tópico na área que diz respeito e, lá, debateremos as ideias específicas.

 

Agora quanto aos assuntos "globais", que, creio eu, devem ser tratados aqui, a primeira coisa que me veio à cabeça é: Se vamos falar tanto de ideias, devemos entrar num consenso se adotaremos ou não as novas regras ortográficas. Li muito ideia acentuado por aqui.

 

Como vi que o desenrolar do banco está parado, acho que ainda dá tempo de dar a minha sugestão:

Um tipo de padronização que me ensinaram e eu gostei é que o nome das tabelas é completo e tem o nome do seu assunto no singular.

 

Seguindo a proposta CamelCase do JBN

idUser (chave primária, auto numeração)

userName (chave única, indexável)

userRealName (indexável)

userEmail

userPswd (hash da senha do usuário)

userSite (URL do site do usuário)

userReputation (avaliação dada por outros membros, esse campo terá valor máximo como 100)

o resultado fica assim:

Tabela usuario

UsuarioId

UsuarioNomeLogin

UsuarioSenha

UsuarioEmail

UsuarioNome

UsuarioSite

UsuarioReputacao

Uso de FW:

PHP -> Dispenso, principalmente se o intuito é integrar os principiantes.

JS -> Achei interessante a idéia do front-end em jQuery e administrativo em Ext mas, o que vocês entendem por administrativo?

[RafaelReis 0]

Pessoal eu criei uma rede social sozinho está pronta, se quizer eu posso colocar em algum site com o 4sherad, e vcs baixam !!!!

 

levinha não passa de 1MB

[Duardaum 0]

Posso encabeçar o front-end (x)html/css se mais ninguém da área estiver disposto.

 

Farei a "distribuição de tarefas" e revisão dos trabalhos além, claro, de dar a minha partezinha de marcação. Me disponho à orientação e debate sobre semântica na marcação e alternativas com CSS. Mas resumo a tarefa por aqui para não misturar muito com o foco do tópico. Como dito, se mais ninguém desejar o "posto", crio o Tópico na área que diz respeito e, lá, debateremos as ideias específicas.

 

Agora quanto aos assuntos "globais", que, creio eu, devem ser tratados aqui, a primeira coisa que me veio à cabeça é: Se vamos falar tanto de ideias, devemos entrar num consenso se adotaremos ou não as novas regras ortográficas. Li muito ideia acentuado por aqui.

 

Como vi que o desenrolar do banco está parado, acho que ainda dá tempo de dar a minha sugestão:

Um tipo de padronização que me ensinaram e eu gostei é que o nome das tabelas é completo e tem o nome do seu assunto no singular.

 

Seguindo a proposta CamelCase do JBN

idUser (chave primária, auto numeração)

userName (chave única, indexável)

userRealName (indexável)

userEmail

userPswd (hash da senha do usuário)

userSite (URL do site do usuário)

userReputation (avaliação dada por outros membros, esse campo terá valor máximo como 100)

o resultado fica assim:

Tabela usuario

UsuarioId

UsuarioNomeLogin

UsuarioSenha

UsuarioEmail

UsuarioNome

UsuarioSite

UsuarioReputacao

Uso de FW:

PHP -> Dispenso, principalmente se o intuito é integrar os principiantes.

JS -> Achei interessante a idéia do front-end em jQuery e administrativo em Ext mas, o que vocês entendem por administrativo?

 

 

Olá pessoal,

 

Também estou aqui a disposição como falei anteriormente para ajudar nos assuntos consizentes a banco de dados.

Eu particularmente preferiría o PostgreSql que ele é mais interativo com php seguro e fácil de manipular.

Mais já que escolheram o Mysql tudo bem, vou ajudar nele rsr.

 

Eu estou quase terminando minha faculdade de Sistemas de Informação e sou Técnico em informática formado.

 

Gostaria de dar uma opinião sobre como desenvolver o banco de dados dessa rede social.

Todo o banco de dados é relacional, eu ouvi rumores por ai de que já se estavam pensando em criar

um banco orientado a objeto, mais enquanto isso não ocorre, vamos planejar a base de dados orientada a objetos.

 

Como nosso amigo postou acima falando de como deveria se comportar as tabelas do banco, dessa forma que foi colocada,

vai ficar fora dos padrões recomendados pelas Forma Normal para Banco de dados então, gostaria de recomendar que ficasse dessa forma, para que quando fosse fazer a instãncia de um objeto

com os resultados de uma tabela ou view do banco de dados por exemplo, ficar facil a amostragem desses dados depois. Exemplo:

 

Método apresentado da tabela usuário:
$sql = "SELECT * FROM usuarios WHERE UsuarioId = '1' LIMIT 1";
$result = mysql_query($sql) or die (mysql_error());

$objUsuario = mysql_fetch_object($result);

echo $objUsuario->UsuarioId
echo $objUsuario->UsuarioNomeLogin
echo $objUsuario->UsuarioSenha e etc..

Ficaria muito estranho e resundânte o nome dos campos, colocando esse 'Usuario' sempre na frente dos campos da tabela

que a gente já sabe que é de usuário.

 

Eu recomendo o seguinte:

 

Recomendação:

Tabela Usuário:

CREATE TABLE usuarios (
  id INT4 AUTO_INCREMENT NOT NULL,
  login VARCHAR(20) NOT NULL,
  crypsenha VARCHAR(70) NOT NULL COMMENT 'Campo criptografado com SHA1 ou MD5 do mysql para ninguem saber a senha, nem a gente mesmo',
  email VARCHAR(80) NOT NULL,
  nome VARCHAR(100) NOT NULL COMMENT 'para poder colocar o nome completo caso queira',
  reputacao INT NOT NULL COMMENT 'não sei qual é a idéia deste campo mais poderia ser contado com pontos somados de 1 em 1',
  PRIMARY KEY(id),
  UNIQUE(login, email)
);

Colocar os campos 'site' em uma outra tabela como a tabela 'perfil' por exemplo.

Na hora de instânciar ficaria assim:

 

$sql = "SELECT * FROM usuarios WHERE id = '1' LIMIT 1";
$result = mysql_query($sql) or die (mysql_error());

$objUsuario = mysql_fetch_object($result);

echo $objUsuario->id;
echo $objUsuario->login;
echo $objUsuario->nome;

e etc..

Aplicando o mesmo conceito para todas as outras tabelas, deixando a base de dados mais organizada

e caso precisemos fazer alguma alteração, fique de fácil identificação ou até mesmo alteração!!

 

Minha humilde e simples opinião..

 

Grato a todos!!

[augustoclaro 2]

poem aí pro favor

[Evandro Oliveira 331]

@Duardaum, observação perfeita! Com uma exceção: quando tratamos de aplicações genéricas.

 

Pelo pouco que conheço sobre o idealizador e principal desenvolvedor do projeto, tenho quase certeza que o módulo de gerenciamento do banco será baseado em PDO ou algum pacote similar que permita que os dados sejam amarrados (bind) a um tipo de valor.

 

Para alguns tipos primários de valores (como strings por exemplo), os objetos já estão definidos e suas interfaces documentadas.

Como sabemos que pode ser uma falha grave em alguns casos, utilizar o wildcard * para consultas, além de arrastar a performance, nós temos o trunfo que conheceremos nossa aplicação e poderemos passar as consultas de forma inteligente, escolhendo os campos a serem resgatados e, porque não, dando um nome mais amigável para os mesmos.

 

SELECT `usuarioId` AS `id` FROM `usuario` WHERE `id` = 1

 

O problema estaria resolvido. Como se não bastasse, ainda temos a vantagem (já citada) de amarrar cada campo da consulta a uma variável de tipo(classe) definido. Basta dar o nome que julgarmos mais amigável para a mesma.

 

Creio que isso não seja assunto para ser discutido neste tópico, apenas para ficar como tréplica ao seu comentário que foi muito bem aceito (pelo menos por mim).

 

Quanto a futuras discussões e sugestões relacionadas ao banco, atenhamo-nos aqui.

[João Batista Neto 448]

Todo o banco de dados é relacional

 

Opz....

 

Nem todo banco de dados é relacional e, as grandes aplicações estão migrando para o modelo não relacional ou NoSQL.

 

Além do MySQL e do PGSQL, que são relacionais, sugerimos também Cassandra que é tabular e o MongoDB que é orientado à documentos.

 

vai ficar fora dos padrões recomendados pelas Forma Normal para Banco de dados então, gostaria de recomendar que ficasse dessa forma, para que quando fosse fazer a instãncia de um objeto

Exemplo:

 

echo $objUsuario->UsuarioId
echo $objUsuario->UsuarioNomeLogin
echo $objUsuario->UsuarioSenha e etc..

Ficaria muito estranho e resundânte o nome dos campos, colocando esse 'Usuario' sempre na frente dos campos da tabela

que a gente já sabe que é de usuário.

 

Acredite, não trabalharemos dessa forma. :D

 

Eu recomendo o seguinte:

 

CREATE TABLE usuarios (
 id INT4 AUTO_INCREMENT NOT NULL,
 login VARCHAR(20) NOT NULL,
 crypsenha VARCHAR(70) NOT NULL COMMENT 'Campo criptografado com SHA1 ou MD5 do mysql para ninguem saber a senha, nem a gente mesmo',
 email VARCHAR(80) NOT NULL,
 nome VARCHAR(100) NOT NULL COMMENT 'para poder colocar o nome completo caso queira',
 reputacao INT NOT NULL COMMENT 'não sei qual é a idéia deste campo mais poderia ser contado com pontos somados de 1 em 1',
 PRIMARY KEY(id),
 UNIQUE(login, email)
);

Isso, talvez, funcione para aplicações pequenas, mas em aplicações de grande porte, isso trará inúmeros problemas e, entre eles, a ambiguidade.

 

Imagine 2 tabelas:

 

Usuários

id MEDIUMINT
nome VARCHAR

 

Ideias

id MEDIUMINT
ideia VARCHAR

 

Pense que, como vamos relacionar uma ideia com um usuário, precisamos ter uma ligação entre elas.

 

Se colocarmos um idUsuarios na tabela Ideias, teremos o seguinte:

 

Ideias

id MEDIUMINT
idUsuarios MEDIUMINT
conteudo VARCHAR

 

Dessa forma:

 

SELECT `conteudo` FROM `Ideias` LEFT JOIN `Usuarios` ON (`id`=`idUsuarios`);

 

Percebeu ? (o `id` no JOIN refere-se à Ideias ou Usuários ?)

 

Como a coluna id existe tanto em Ideias quanto em Usuarios, ela é ambígua no contexto do relacionamento.

 

Quando modelamos as tabelas assim:

 

Usuarios

idUsuarios MEDIUMINT
usuariosNome VARCHAR

 

Ideias

idIdeias MEDIUMINT
idUsuarios MEDIUMINT
ideiasConteudo VARCHAR

 

Podemos utilizar:

 

SELECT `ideiasConteudo` FROM `Ideias` LEFT JOIN `Usuarios` USING(`idUsuarios`)

 

Percebe agora ?

 

Como não existe ambiguidade, a estrutura léxica da consulta é mais simples.

 

;)

 

Pelo pouco que conheço sobre o idealizador e principal desenvolvedor do projeto, tenho quase certeza que o módulo de gerenciamento do banco será baseado em PDO ou algum pacote similar que permita que os dados sejam amarrados (bind) a um tipo de valor.

 

Iremos abstrair, inclusive, o acesso a dados.

 

Nosso CRUD será modelado pensando na escalabilidade e, todos já tivemos demonstrações (pelas grandes aplicações) que o modelo relacional não é eficiente.

 

Dessa forma, abstrairemos o SQL e o acesso a dados de forma que, caso necessário, possamos mudar para um modelo não relacional, sem que a aplicação sofra com essa modificação.

 

Independente de utilizar SQL ou NoSQL, teremos sim, uma validação forte de tipagem server side, não aceitaremos, sob hipótese alguma, uma informação como ponto flutuante (ou qualquer outro tipo inesperado), onde era esperado um número inteiro.

 

;)

[Duardaum 0]

Opz....

 

Nem todo banco de dados é relacional e, as grandes aplicações estão migrando para o modelo não relacional ou NoSQL.

 

Além do MySQL e do PGSQL, que são relacionais, sugerimos também Cassandra que é tabular e o MongoDB que é orientado à documentos.

 

 

Reconheco que exista outros bancos de dados que orientados a outros tidos, mais a maior questão que eu quis dizer sobre isso era que,

por uma aplicação deste porte, poderemos usar tanto o Mysql ou o PostgreSql que, são S.G.B.D's. com capacidade de vários acessos simultâneos

a base de dados pela rede.

 

Eu recomendo o seguinte:

CREATE TABLE usuarios (
 id INT4 AUTO_INCREMENT NOT NULL,
 login VARCHAR(20) NOT NULL,
 crypsenha VARCHAR(70) NOT NULL COMMENT 'Campo criptografado com SHA1 ou MD5 do mysql para ninguem saber a senha, nem a gente mesmo',
 email VARCHAR(80) NOT NULL,
 nome VARCHAR(100) NOT NULL COMMENT 'para poder colocar o nome completo caso queira',
 reputacao INT NOT NULL COMMENT 'não sei qual é a idéia deste campo mais poderia ser contado com pontos somados de 1 em 1',
 PRIMARY KEY(id),
 UNIQUE(login, email)
);

Isso, talvez, funcione para aplicações pequenas, mas em aplicações de grande porte, isso trará inúmeros problemas e, entre eles, a ambiguidade.

 

Imagine 2 tabelas:

 

Usuários

id MEDIUMINT
nome VARCHAR

 

Ideias

id MEDIUMINT
ideia VARCHAR

 

Pense que, como vamos relacionar uma ideia com um usuário, precisamos ter uma ligação entre elas.

 

Se colocarmos um idUsuarios na tabela Ideias, teremos o seguinte:

 

Ideias

id MEDIUMINT
idUsuarios MEDIUMINT
conteudo VARCHAR

 

Dessa forma:

 

SELECT `conteudo` FROM `Ideias` LEFT JOIN `Usuarios` ON (`id`=`idUsuarios`);

 

Percebeu ? (o `id` no JOIN refere-se à Ideias ou Usuários ?)

 

Como a coluna id existe tanto em Ideias quanto em Usuarios, ela é ambígua no contexto do relacionamento.

 

Quando modelamos as tabelas assim:

 

Usuarios

idUsuarios MEDIUMINT
usuariosNome VARCHAR

 

Ideias

idIdeias MEDIUMINT
idUsuarios MEDIUMINT
ideiasConteudo VARCHAR

 

Podemos utilizar:

 

SELECT `ideiasConteudo` FROM `Ideias` LEFT JOIN `Usuarios` USING(`idUsuarios`)

 

Percebe agora ?

 

Como não existe ambiguidade, a estrutura léxica da consulta é mais simples.

 

;)

Mano, esse colocação e utilizada justamente ao contrário do que você está pensando.

É em justamente em Aplicações de Grande porte, que se deve organizar o banco de dados

com as tabelas com nomes sujestivos e os campos das mesmas mais sujestivos ainda.

 

Quanto a relação:

Olhe:

CREATE TABLE usuarios (
id INT4 AUTO_INCREMENT NOT NULL,
login VARCHAR(20) NOT NULL,
senha VARCHAR(12) NOT NULL,
PRIMARY KEY(id)
);

CREATE TABLE perfil (
id INT4 AUTO_INCREMENT NOT NULL,
idusuario INT4 NOT NULL,
site VARCHAR(50) NOT NULL,
PRIMARY KEY(id)
);

Criando os Inserts:

 

INSERT INTO usuarios VALUES ('1', 'duardaum', '123456'), ('2', 'outro_usuario', '123456');
INSERT INTO perfil VALUES (default, '1', 'www.duardaum.com.br'), (default, 'www.outrousuario.com.br');

Montando um SELECT para buscar o código do usuário, o login do usuário e o seu endereço de site:

SELECT u.id, u.login, p.site
FROM usuarios u
INNER JOIN perfil p
ON u.id = p.idusuario
ORDER BY u.login ASC;

Resultado:

id | login         | site
----------------------------------------
1  | duardaum      | www.duardaum.com.br
2  | outro_usuario | www.outrousuario.com.br

Não sei se você já viu falar em álias em banco de dados.

Álias: é o modo que a gente utiliza para dar apilidos tanto aos campos, como tabelas como visões

no banco de dados.

 

se você perceber eu dei um álias para a tabela 'usuarios' que foi a letra 'u' e outro para a tabela

'perfil que foi a letra 'p'.

 

Desta forma, não há a menor possibilidade de redundância de nomes de campos e nem como se confundir

em qual campo pertence a qual tabela, e ficará mais facil de identificar para que serve cada campo da tabela,

sem contar com os comentários que deverão ser feitos tanto nas tabelas quanto nos campos que forem ligeiramente

demorados ou difíceis a compreenção, facilitando assim para todos o uso da base de dados.

 

Espero que você não fique chateado comigo, assim como não fiquei com você.

Gosto de debater, isso faz com que cresçamos profissionalmente, conhecendo sempre mais e mais

daquilo que trabalhamos.

 

E quanto ao projeto da Rede social, gostaria de dar uma dica:

 

Fazer com que tudo que for possível, possa ficar no banco de dados.

Dessa forma, quando for fazer qualquer alteração na rede social, façam as modificações no banco

e não precisa mecher na aplicação.

 

E quam for desenvolver a aplicação:

 

Fazer a aplicação de modo que ele possa se adequar dinamicamente a entrada de novos valores

para poder não danificar o layout de acordo com as modificações que futuramente possam vir ocorrer.

[João Batista Neto 448]

Mano, esse colocação e utilizada justamente ao contrário do que você está pensando.

É em justamente em Aplicações de Grande porte, que se deve organizar o banco de dados

com as tabelas com nomes sujestivos e os campos das mesmas mais sujestivos ainda.

 

<_<

[Matias Rezende 50]

Mano, esse colocação e utilizada justamente ao contrário do que você está pensando.

É em justamente em Aplicações de Grande porte, que se deve organizar o banco de dados

com as tabelas com nomes sujestivos e os campos das mesmas mais sujestivos ainda.

 

Quanto a relação:

Olhe:

CREATE TABLE usuarios (
id INT4 AUTO_INCREMENT NOT NULL,
login VARCHAR(20) NOT NULL,
senha VARCHAR(12) NOT NULL,
PRIMARY KEY(id)
);

CREATE TABLE perfil (
id INT4 AUTO_INCREMENT NOT NULL,
idusuario INT4 NOT NULL,
site VARCHAR(50) NOT NULL,
PRIMARY KEY(id)
);

Criando os Inserts:

 

INSERT INTO usuarios VALUES ('1', 'duardaum', '123456'), ('2', 'outro_usuario', '123456');
INSERT INTO perfil VALUES (default, '1', 'www.duardaum.com.br'), (default, 'www.outrousuario.com.br');

Montando um SELECT para buscar o código do usuário, o login do usuário e o seu endereço de site:

SELECT u.id, u.login, p.site
FROM usuarios u
INNER JOIN perfil p
ON u.id = p.idusuario
ORDER BY u.login ASC;

Agora, vamos refazer a estrutura que você colocou e a consulta.

 

CREATE TABLE usuario (
idUsuario INT4 AUTO_INCREMENT NOT NULL,
usuarioLogin VARCHAR(20) NOT NULL,
usuarioSenha VARCHAR(12) NOT NULL,
PRIMARY KEY(idUsuario)
);

CREATE TABLE perfil (
idPerfil INT4 AUTO_INCREMENT NOT NULL,
idUsuario INT4 NOT NULL,
perfilSite VARCHAR(50) NOT NULL,
PRIMARY KEY(idPerfil)
);

 

Fazendo a consulta

SELECT idUsuario, usuarioLogin as 'login', perfilSite as 'site'
FROM usuario
JOIN perfil USING ('idUsuario')
ORDER BY login ASC;

 

Viu como a consulta fica mais simples e mais legível assim? Eu, particularmente, não gosto de criar alias na consulta, mas isto é só gosto pessoal.

 

Carlos Eduardo

[João Batista Neto 448]

Viu como a consulta fica mais simples e mais legível assim? Eu, particularmente, não gosto de criar alias na consulta, mas isto é só gosto pessoal.

 

Não apenas simples, Fica elegante.

 

Agora, se tivermos 50 tabelas, no modelo proposto pelo Duardaum teríamos 50 colunas id, isso sim é desorganizado para mim.

 

Agora,

 

Mano, esse colocação e utilizada justamente ao contrário do que você está pensando. É em justamente em Aplicações de Grande porte, que se deve organizar o banco de dados com as tabelas com nomes sujestivos e os campos das mesmas mais sujestivos ainda

 

CREATE TABLE `tyfu`.`Usuario` (
`idUsuario` MEDIUMINT(8) UNSIGNED NOT NULL AUTO_INCREMENT ,
`usuarioNome` VARCHAR(45) NULL ,
`usuarioEmail` VARCHAR(45) NULL ,
PRIMARY KEY (`idUsuario`)
);

 

Sei lá mas, não acredito que exista uma forma em que o nome da tabela e seus campos fiquem mais sugestivos que a forma descrita acima.

 

;)

[Evandro Oliveira 331]

Montando um SELECT para buscar o código do usuário, o login do usuário e o seu endereço de site:

SELECT u.id, u.login, p.site
FROM usuarios u
INNER JOIN perfil p
ON u.id = p.idusuario
ORDER BY u.login ASC;

Beleza, agora, num mundo muito distante e improvável, nós poderíamos dar "nomes" para as idéias, além dos usuários também possuírem "nomes"

 

CREATE TABLE `usuario`(
   `id`    MEDIUMINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
   `nome`  VARCHAR(20)
);

CREATE TABLE `ideia`(
   `id`    MEDIUMINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
   `nome`  VARCHAR(15),
   `autor` MEDIUMINT UNSIGNED NOT NULL,
   -- índices, chaves estrangeiras e etc.
);

SELECT
   `i`.`id`,
   `i`.`nome`,
   `u`.`nome`
FROM
   `ideias` AS `i`
JOIN
   `usuario` AS `u` ON `u`.`id` = `i`.`autor`;

 

 

Como fica??? ^^

[Duardaum 0]

A idéia é realmente poder colocar todos os dados no banco,

indiferentemente se vão ter 10, 20, 50 ou 1000 tabelas.

 

Como disseram acima, tudo é questão de gosto.

 

Eu defendo essa idéia por que eu sou DBA e organizar no banco, garante a integridade dos dados

e a certeza de que os dados foram realmente inseridos e estam válidos,

fazendo com que todas as tabelas tenha seus dados preencidos.

 

Mais como 1 não vence 10, é apenas uma idéia.

 

O banco possui muito mais coisas do que simplesmente tabela

como vocês sabem, alem das tabelas, em uma base de dados você poderá criar tbm:

 

Views;

Procedures Storages;

Domains;

 

E nas tabelas validar com funções nativas que possuem em cada um dos S.G.B.D's.

Dessa forma, a quantidade de código em PHP que será desenvolvido será muitíssimo pequena.

 

Mais estamos ai, diferentemente da decisão de vocês

 

Montando um SELECT para buscar o código do usuário, o login do usuário e o seu endereço de site:

SELECT u.id, u.login, p.site
FROM usuarios u
INNER JOIN perfil p
ON u.id = p.idusuario
ORDER BY u.login ASC;

Beleza, agora, num mundo muito distante e improvável, nós poderíamos dar "nomes" para as idéias, além dos usuários também possuírem "nomes"

 

CREATE TABLE `usuario`(
   `id`    MEDIUMINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
   `nome`  VARCHAR(20)
);

CREATE TABLE `ideia`(
   `id`    MEDIUMINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
   `nome`  VARCHAR(15),
   `autor` MEDIUMINT UNSIGNED NOT NULL,
   -- índices, chaves estrangeiras e etc.
);

SELECT
   `i`.`id`,
   `i`.`nome`,
   `u`.`nome`
FROM
   `ideias` AS `i`
JOIN
   `usuario` AS `u` ON `u`.`id` = `i`.`autor`;

 

 

Como fica??? ^^

 

Primeiro que não vai funcionar esse SELECT pois as tabelas nao estão relacionadas.

Se tivesse o 'id' do usuario na tabela 'ideia' ficaria assim:

 

SELECT i.id, i.nome as ideia, u.nome as usuario 
FROM usuario u
INNER JOIN ideias i
ON i.idusuario = u.id;

Exemplo de resultadoque seria dessa forma:

 

id | ideia              | usuario
---------------------------------------
1  | A idéia do usuario | login_usuario