Re: problem with table structure

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(at)tim-landscheidt(dot)de>wrote:

> Miguel Vaz <pagongski(at)gmail(dot)com> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>