I currently have two tables:
1: users
id_user
username

2: baned_users
id_user

i tought i could use something like this
1: users
id_user
username
is_baned

So would it be better to use two tables like in first example or one
table like in second example? Offcourse, not many users would be baned
(i hope). I currently have 59 joins with baned_users table in my
stored procedures, two of those are executed on every access to the
website (2xtop 20 users), what way should i use?

Sorry for my bad english.

Think in Sets! A table can be a set of entities and that table must
have *all* for the attributes of that entity. I think you need an
"access_status" attribute in the Users table or you need a
relationship table that puts a user_id and a resource_id paired.

>> Sorry for my bad English. <<

No problem. Please post DDL, so that people do not have to guess what
the keys, constraints, Declarative Referential Integrity, data types,
etc. in your schema are. Sample data is also a good idea, along with
clear specifications. It is very hard to debug code when you do not
let us see it.

Igor wrote:

> I currently have two tables:
> 1: users
> id_user
> username
>
> 2: baned_users
> id_user
>
> i tought i could use something like this
> 1: users
> id_user
> username
> is_baned
>
> So would it be better to use two tables like in first example or one
> table like in second example? Offcourse, not many users would be baned
> (i hope). I currently have 59 joins with baned_users table in my
> stored procedures, two of those are executed on every access to the
> website (2xtop 20 users), what way should i use?

I recommend the second method (one table). Using a separate table
should be reserved for situations where a subset of users have
significant amounts of extra data (e.g. blobs for the top 20 users).

Igor (jerosimic@gmail.com) writes:
> I currently have two tables:
> 1: users
> id_user
> username
>
> 2: baned_users
> id_user
>
> i tought i could use something like this
> 1: users
> id_user
> username
> is_baned
>
> So would it be better to use two tables like in first example or one
> table like in second example? Offcourse, not many users would be baned
> (i hope). I currently have 59 joins with baned_users table in my
> stored procedures, two of those are executed on every access to the
> website (2xtop 20 users), what way should i use?

The second design is the more natural design in my opinion. There could
be situations where the first design is better for performance, if you
often need to review the list of banned users, but that does not seem to
be a critical task in this case.


--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

On Apr 17, 12:18 am, Erland Sommarskog <esq...@sommarskog.se> wrote:
> Igor (jerosi...@gmail.com) writes:
> > I currently have two tables:
> > 1: users
> > id_user
> > username
>
> > 2: baned_users
> > id_user
>
> > i tought i could use something like this
> > 1: users
> > id_user
> > username
> > is_baned
>
> > So would it be better to use two tables like in first example or one
> > table like in second example? Offcourse, not many users would be baned
> > (i hope). I currently have 59 joins with baned_users table in my
> > stored procedures, two of those are executed on every access to the
> > website (2xtop 20 users), what way should i use?
>
> The second design is the more natural design in my opinion. There could
> be situations where the first design is better for performance, if you
> often need to review the list of banned users, but that does not seem to
> be a critical task in this case.
>
> --
> Erland Sommarskog, SQL Server MVP, esq...@sommarskog.se
>
> Books Online for SQL Server 2005 athttp://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
> Books Online for SQL Server 2000 athttp://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

OK thank you all, i think i'll go with the one table then.