bergonzzi Posted July 19, 2006 at 04:06 PM Report #39079 Posted July 19, 2006 at 04:06 PM Ois pessoal, Gostava que alguém mais experiente em bases de dados me desse umas dicas sobre como organizar uns dados em tabelas. Contextualizando.. tenho uma tabela "PARQUES" com vários campos que descrevem os detalhes de parques de campismo (nome, morada, telefone, etc.). A questão é que cada parque de campismo tem também uma tabela de preços. E aqui se coloca o problema, como é que eu hei-de enfiar uma tabela de preços num record referente a um parque? Mais.. a tabela de preços tem um número fixo de colunas (são 9) mas as rows já não são fixas, podendo ser apenas uma ou cerca de 16 no máximo. Para tornar as coisas ainda mais difíceis, enquanto que os headers das colunas têm nomes ou labels fixos (nem precisam de estar na BD), as rows têm nomes dinâmicos, ou seja dependem do parque em questão. Só para ilustrar a tabela de preços.. ---------------------------------- época | criança | adulto | tenda ---------------------------------- alta | | | baixa | | | natal | | | páscoa | | | ---------------------------------- As colunas são sempre essas (na realidade são mais mas é só para simplificar). As linhas é que, em alguns parques só há uma época, noutros há estas todas, e noutros há mais ainda. Resumindo, qual será a melhor maneira de fazer com que cada record na tabela PARQUES tenha associado uma tabela de preços semelhante a esta..?
vbtipo Posted July 19, 2006 at 07:58 PM Report #39120 Posted July 19, 2006 at 07:58 PM Assim como estas a propôr o teu problema não consigo saber practicamente grande coisa, mas para aquilo que precibi é o seguinte: tens que utilizar um campo identificatifo da tabela Parques (ou seja, uma chave primaria que definiste) nesta dos preços. Se faltar mais alguma coisa não sei porque não tenho mais elementos. Lema: Se eu não saber de alguma coisa não se preocupem porque tento sempre ajudar alguma coisita, nem que seja, por palpites/sugestões.
bergonzzi Posted July 20, 2006 at 02:47 AM Author Report #39170 Posted July 20, 2006 at 02:47 AM Se calhar não fui claro.. As chaves primárias e as relações entre as tabelas já está tudo definido, mas a questão aqui é outra. O que se passa é que cada parque de campismo (= 1 record na tabela PARQUES) tem uma tabela de preços. Esquecendo agora as particularidades dessa tabela de preços, a minha dúvida é: qual a melhor maneira de colocar uma tabela de preços para cada parque, seja na mesma tabela, seja numa tabela separada. No fundo a minha dúvida é como representar uma tabela dentro de uma tabela.
vbtipo Posted July 20, 2006 at 06:15 AM Report #39175 Posted July 20, 2006 at 06:15 AM Pões tudo relacionado com os preço numa única tabela depois quando quizeres obter os resultados de um terminado parque é só usares os filtros. Lema: Se eu não saber de alguma coisa não se preocupem porque tento sempre ajudar alguma coisita, nem que seja, por palpites/sugestões.
Saco Posted July 20, 2006 at 10:37 AM Report #39199 Posted July 20, 2006 at 10:37 AM Eu não sou nenhum mestre em Bases de Dados, na verdade toda a minha experiencia se resume a uma cadeira da faculdade mas... Na minha opinião o que tu precisas é de criar mais duas tabelas, uma tabela com as epocas e uma tabela com os precos. Assim cada preço fica associado a uma época e a um parque de campismo. Acho que resolve o teu problema.
M6 Posted July 20, 2006 at 05:43 PM Report #39268 Posted July 20, 2006 at 05:43 PM A melhor solução é teres uma tabela de preços ligada com uma foreign key (FK, aka chave estrangeira) que liga à primary key chave (PK, aka chave primária). Cada registo na tabela Parques terá "n" registos na tabela de preços, ou seja, cada parque pode ter vários preços- 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
bergonzzi Posted July 20, 2006 at 06:49 PM Author Report #39283 Posted July 20, 2006 at 06:49 PM SacoPlastico, acho que isso até era capaz de resultar mas não sei se não se iria tornar complexo demais quando fosse pra fazer querys.. M6, o prob. é que como podes ver na tabela de exemplo em baixo, as épocas que estão na primeira coluna, variam de parque para parque. E depois.. tou aqui a imaginar como seria o interface para inserir estes dados no CMS..! Dá vontade de meter as tabelas em excel e mandar o gajo ler on-the-fly.. 🙂 Vejam lá um exemplo duma das tabelas mais preenchidas que pode vai existir: http://img388.imageshack.us/img388/4721/tabpreoshv8.gif
Saco Posted July 21, 2006 at 12:30 AM Report #39318 Posted July 21, 2006 at 12:30 AM As queries não ficam nada muito complexas... assim até tens a opção de só sacar os preços de uma determinada época. Ou então podes fazer uma pequena modificação e em vez de teres uma tabela para as épocas incluis a época numa coluna da tabela de preços tal como disse o M6. Só acho a minha opção mais apropriada no sentido de garantires uma melhor homogeneidade na denominação das épocas...
M6 Posted July 21, 2006 at 08:25 AM Report #39324 Posted July 21, 2006 at 08:25 AM As queries não ficam nada muito complexas... assim até tens a opção de só sacar os preços de uma determinada época. Exacto. As nossas opiniões convergem e são a solução correcta para este problema. Ou então podes fazer uma pequena modificação e em vez de teres uma tabela para as épocas incluis a época numa coluna da tabela de preços tal como disse o M6. Só acho a minha opção mais apropriada no sentido de garantires uma melhor homogeneidade na denominação das épocas... Também concordo. A separação por épocas é a abordagem que melhor resolve este problema. 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
bergonzzi Posted July 21, 2006 at 10:07 AM Author Report #39344 Posted July 21, 2006 at 10:07 AM Acho que já estou a entender um bocado melhor, seria muito abusador se vos pedisse um peq. esquema das tabelas como vcs estão a dizer? Agradeço imenso a ajuda! 😁
Saco Posted July 21, 2006 at 10:31 AM Report #39349 Posted July 21, 2006 at 10:31 AM ora bem, tendo em conta os dados que tens vindo a apresentar seria qualquer coisa do genero... (agora não me peças é codigo SQL) PARQUES ID nome (...) EPOCAS ID nome (...) PRECOS ID ID_parque (que liga esta tabela à tabela parques) ID_epoca (que liga esta tabela à tabela epocas) ADULTO CRIANCA TENDAP. TENDAG. ROULOTTE CARAVANA CARRO MOTA quanto a chaves primárias seriam os ID de cada tabela, claro está, e nunca percebi bem o conceito de chave estrangeira, mas provavelmente ID_parque e ID_epoca da tabela PRECOS podem ser chaves estrangeiras...
bergonzzi Posted July 21, 2006 at 11:59 AM Author Report #39365 Posted July 21, 2006 at 11:59 AM Ahhhhhhh ta bem, agora ficou bem mais claro! B) Chave estrangeira é uma chave não primária numa tabela que corresponde à chave primária noutra tabela. Já agora.. será que a tabela EPOCAS não deveria estar também ligada à tabela PARQUES, ficando assim: EPOCAS ----------- ID (PK) ID_parque (FK) nome (...) Isto por causa da tal questão: cada parque tem sempre épocas diferentes. Quer dizer, por vezes podem coincidir mas para "normalizar" a estrutura é melhor partir do princípio que é sempre diferente. Só que assim isto também pode levar a records duplicados na tabela épocas, nos casos em que muitos parques têm por ex. uma única época..
M6 Posted July 21, 2006 at 12:47 PM Report #39375 Posted July 21, 2006 at 12:47 PM ora bem, tendo em conta os dados que tens vindo a apresentar seria qualquer coisa do genero... (agora não me peças é codigo SQL) PARQUES ID nome (...) EPOCAS ID nome (...) PRECOS ID ID_parque (que liga esta tabela à tabela parques) ID_epoca (que liga esta tabela à tabela epocas) ADULTO CRIANCA TENDAP. TENDAG. ROULOTTE CARAVANA CARRO MOTA quanto a chaves primárias seriam os ID de cada tabela, claro está, e nunca percebi bem o conceito de chave estrangeira, mas provavelmente ID_parque e ID_epoca da tabela PRECOS podem ser chaves estrangeiras... Não podem, são. A chave estrangeira não é mais do que um apontador de um registo de uma tabela para a chave de outro registo de outra tabela. A tabela de preços pode ainda ser generalizada para flexibilizar o tipo de pessoa/equipamento, ou seja, havendo outra tabela onde se colocasse essa informação, permitiria uma gestão por parte do utilizador, tornando a aplicação mais flexivel. 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
M6 Posted July 21, 2006 at 12:50 PM Report #39377 Posted July 21, 2006 at 12:50 PM Ahhhhhhh ta bem, agora ficou bem mais claro! B) Chave estrangeira é uma chave não primária numa tabela que corresponde à chave primária noutra tabela. Não obrigatoriamente, uma chave estrangeira pode pertencer à chave primária de uma tabela. Já agora.. será que a tabela EPOCAS não deveria estar também ligada à tabela PARQUES, ficando assim: EPOCAS ----------- ID (PK) ID_parque (FK) nome (...) Isto por causa da tal questão: cada parque tem sempre épocas diferentes. Quer dizer, por vezes podem coincidir mas para "normalizar" a estrutura é melhor partir do princípio que é sempre diferente. Só que assim isto também pode levar a records duplicados na tabela épocas, nos casos em que muitos parques têm por ex. uma única época.. Não é necessário. A estrutura está normalizada. A combinação ID_parque e ID_epoca na tabela PRECOS quer dizer que um determinado parque numa determinada época tem um determinado conjunto de preços. 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
bergonzzi Posted July 21, 2006 at 11:33 PM Author Report #39499 Posted July 21, 2006 at 11:33 PM Pessoal, acho que depois já não chateio mais, mas desde já obrigado pq me ajudaram bastante. B) Queria só que dessem uma última olhadela nas relações, vou fazer a BD em access primeiro para fazer umas experiências e ver se funciona tudo bem, depois reproduzo em MySql: http://img503.imageshack.us/my.php?image=relationshipscampismogq5.jpg
vbtipo Posted July 22, 2006 at 10:21 AM Report #39550 Posted July 22, 2006 at 10:21 AM Acho que falta alguma coisa em relação dos parques, imaginando que pões esta base de dados numa página web ou mesmo no programa só destinado a parques. 1 - Como é que vais dizer que um determinado parque já tem as reservas todas feitas ou ainda falta reservar uma ou algumas áreas para ser reservadas. 2 - Falta ainda dizer que fora daquele determinado tempo de duração o parque está disponivel para futuras ocupações Nota: Se ainda faltar alguma coisa, neste momento me está a escapar. Lema: Se eu não saber de alguma coisa não se preocupem porque tento sempre ajudar alguma coisita, nem que seja, por palpites/sugestões.
bergonzzi Posted July 22, 2006 at 11:50 AM Author Report #39567 Posted July 22, 2006 at 11:50 AM Isto é para um site, mas atenção que não irá ter reservas! O objectivo é criar na net um site agradável e fácil que reúna todos ou quase todos os parques de campismo de uma forma organizada e que permita aos utilizadores não só consultar os dados/fotos dos mesmos mas também deixar reviews e classificações. Tive também uma ideia quer era capaz de ser interessante.. para mostrar o mapa do local do parque, em vez de mostrar em imagem fixa, pensei que talvez desse para utilizar o API do google maps e mostrar uma mapa dinâmico. Tenho as coordenadas de GPS (em formato DMS) de cada parque, é só converter em decimal e tentar chamar o mapa. Já alguém fez isto?
M6 Posted July 22, 2006 at 06:22 PM Report #39632 Posted July 22, 2006 at 06:22 PM Quanto ao modelo de dados apresentado: - a tabela "reviews só necessita do campo id se um utilizador puder fazer mais de uma review para cada parque, caso contrário o campo está a mais; - a tabela "precos" tem a mesma nota acima; - a tabela "epocas" talvez devesse ter um nome ou descrição e não só um intervalo de tempo, para se poder ter algo do género, "Primavera-Verão 2006" - os contactos da tabela "parques", estando OK, poderiam estar numa tabela à parte, havendo depois tipos de contactos e contactos, como disse tal como está está correcto, mas a gestão dos contactos é muitas vezes feita "à parte", depende também das necessidades, por exemplo, um parque pode ter 3 fax e outro pode não ter nenhum. De resto, o modelo parece OK. 😄 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
bergonzzi Posted July 22, 2006 at 07:28 PM Author Report #39650 Posted July 22, 2006 at 07:28 PM Muito obrigado pela revisão 😛 Só não tou a conseguir "visualizar" a razão do campo id estar a mais na tabela 'reviews' e 'precos'.. n tenho muita experiência em bases de dados (como já se deve ter reparado!), tenho tentado aprender por mim próprio então ainda tenho dificuldades e "ver" como é que os dados vão ficar no fim. Portanto a razão.. tem a ver com o facto de qualquer combinação "id_parque/id_user ser única, ou seja, cada user só pode ter um review por parque, ok acho que entretanto já se fez luz, hehe 😛 Na tabela 'precos' é a mm coisa, ou seja, cada parque, para cada época, só tem um conjunto de preços. Estou a ver bem as coisas?
M6 Posted July 22, 2006 at 07:45 PM Report #39654 Posted July 22, 2006 at 07:45 PM O campo uid está lá para ser a chave da tabela, ou seja, o identificador único. Se disseres que a chave primária da tabela é composta pelos dois ids das outras tabelas, ou seja pelas chaves estrangeiras, então tens o problema do identificador único resolvido. No entanto, tal vai apenas permitir um par desses ids em toda a tabela. O que dizes para o caso dos preços está correcto, nesse caso não necessitas do id e podes usar o par de ids das chaves estrangeiras como chave. 😛 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now