I've three tables (definitions below). My real question is there might be multiple "bar" rows per "foo" row. And So I require a "fooToBar" table. Is the best design? What's the title or design pattern of for this kind of situation? it is possible to better reputation for the table than "fooToBar" table? Thanks greatly.
The look you title is perfect for n:m associations. If foo and bar are separate from one another and every foo could be associated with several bars - as well as each bar could be associated with several foos, then this is actually the method of go.
If each bar are only able to be associated with one foo, you are in 1:n associations and may just give a fooID column towards the bar table.
I'd say should you keep your naming convention inside your whole database, plus there is not a problem with this particular title (but correct the capital).
If there might be multiple bars for any single foo, although not the other way round, then you've what's known as a one-to-many relationship between foo and bar. To model this type of relationship you'd give a column named
fooId in bar. There'd be no requirement for a fooToBar table.
However, if there can both be multiple bars for any single foo and multiple foos for any single bar then you've a many-to-many relationship between foo and bar, which necessitates another join table (fooToBar).
Regarding naming convention, It's my job to use proper casing (not camel casing), and affix each database object having a prefix that identifies the applying the item goes to. Also, It's my job to title my many-to-many join tables to ensure that they incorporate what they are called from the other two tables. For instance, basically was building Stackoverflow, I would prefix each database object with so, meaning my tables within the many-to-many example could be named:
I believe furthermore important compared to naming minutia is you select a convention and stick to it.
You'll need the FooToBar table when the foo bar relationship is optional, i.e. if you wish to allow Bar rows which have no corresponding Foo row. Or else you could just place the foo attribute like a foreign type in bar.