Search Postgresql Archives

Re: problem with table structure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Tim: ah, come on. :-P

I do have basic knowledge, and beyond. I am mostly a MySQL dev (dont flame yet), but have a good grasp on bds in general.

I usually solve the BD problems/situations in a way i can easily code around it, since i am normally the dev on the programming front also. This time i am building the BD for someone else, with certain constraints, so my question was more of a general use, or common procedure - if there is one - for that particular problem.

I understand that you, Tim, might be more pragmatic about the whole matter, and please forgive my use of english, which is also not my native language, but its merely what i stated above: i do have knowledge, i can solve the stated situation in a way *I* could work with, but thought of asking you, master SQL'ers, about how you would solve the situation. Just that, no strings attached, no complications needed. :-)

Email is a very ungrateful media for db explanations. It easily becomes boring and extensive, for both the writer and the reader. Still, thanks for the help, guys. :-)

As for the vehicle, Tim, i would prefer the pub, since at the moon is where i usually spend my days, hehe.

Pag



On Fri, Jul 9, 2010 at 7:16 PM, Tim Landscheidt <tim@xxxxxxxxxxxxxxxxxx> wrote:
Miguel Vaz <pagongski@xxxxxxxxx> wrote:

> Thank you for the opinion, Alban. The names are the least of my worries, i
> typed them without thinking. And its portuguese. :-)

> If, using that design, i had a different table with something like arq_types
> { id_arq_type, descr } that i could somehow connect to the generic table
> (the one with the common fields), how could i go about querying those tables
> for all the results of a specific type, for example? Or maybe i could add a
> "table_name" field on that arq_type table?

> Tim:

> Dont consider this to be strictly for archeology, i mean in a generic sense
> that if we have several data sets with common fields, if we could divide
> them into several tables, one with common fields, and the others with fields
> related to each type. My doubt was regarding how to have a separate table
> with "types" that could be used to help query the "common fields table" and
> fetch the corresponding table of that specific type. I understand its a bit
> ungrateful for you guys to understand what i mean, considering that i am
> probably making things even more confusing. :-)
> [...]

I think the main problem is that you haven't stated your ex-
perience with SQL (or databases in general). Your questions
above ("somehow connect to the generic table", "go about
querying those tables") indicate that you seem to be lacking
basic knowledge. In this case, it won't help you, us or your
database to ask how to structure your data; you should read
a tutorial, and then choose a structure that you understand
and that works for you.

 But at the moment, you're basically saying: "I'd like to
build a vehicle; I haven't decided yet whether it should
take me to the next pub or the moon. Which screws should I
use?"

Tim


--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux