A lil help with DB design

I have a table to store members. For each member, I have flags like manager, verified, etc. How should I be storing the flags? As individual columns in the same table and using bit datatype or creating a new table called MemberStatus and creating 1 row for each flag?

Thanx in advance.

Premal.One table.|||no flags, no bit data

just more to interprete|||Option 1. Flags, bits.
1 = true, 0 = false. Not much to interpret.|||1 = true, 0 = false, Null = unknown ;)|||1 = true
0 = false
6 = not sure
9 = not applicable
NULL = unknown|||10 = drop dead gorgeous.|||7 = very fluffy.

-PatP|||to properly account for shades of gray, you should use a decimal.

.983 = high degree of truthiness
.015 = minor fib, won't hurt anyone|||"truthiness" heh

somebody is a big fan of TheDailyWTF

:)|||nah, i got it from Colbert. He invented that word.|||1 = true, 0 = false, Null = unknown ;)

Null does not mean unknown, it means the absence of any value, or non existence|||ah, i see, thanks brett

but ontologically speaking, "absence of any value, or non existence" includes unknown

it also includes not applicable, out of range, optional, forgot, maybe, and WTF!|||ah, i see, thanks brett

but ontologically speaking, "absence of any value, or non existence" includes unknown

it also includes not applicable, out of range, optional, forgot, maybe, and WTF!

Ummm no, unkown mean there's a quanity, but who knows.

Null means there's not even the understanding of any quantity

And I like the words you keep throwing out there

But shouldn't it be anti-ontologically

http://www.allwords.com/word-ontologically.html|||Ooh! NULL FIGHT! NULL FIGHT!|||Is that where you throw null pointer exceptions?

Sorry. Couldn't resist.|||Null fights usually turn out to be "Much Ado About Nothing".|||Ooh! NULL FIGHT! NULL FIGHT!

LOL

This message is too short

A lil confused here from BOL

From BOL : How Transactional Replication Works
"After all Subscribers have received transactions, the Distribution Cleanup
Agent removes delivered transactions in the distribution database. Delivered
transactions are kept in the distribution database for a defined period
known as the retention period. Setting a retention period while scheduling
backups can ensure that information required to recover a destination
database automatically is available within the distribution database.
For example, if a Subscriber has scheduled a transaction log dump of a
destination database every 24 hours, you could set the retention period to
48 hours. Even if the Subscriber experiences a failure immediately before a
scheduled backup, all transactions necessary to restore the replicated
tables automatically will still be available to the distribution process of
the Distributor."
So im confused at the first 2 statements where it says that the cleanup
agent job removes the delivered transaction in the distrib database but then
it also states that those delivered transactions are kept in the distrib
database for a defined period and then gives an example that we could set
the retention period to 48 hrs.. So if the cleanup agent cleans them, how is
it retained ?
Hassan,
they're retained until all subscribers have subscribed or the retention
period is reached, whichever is shorter. In the case of anonymous
subscribers this changes and they're retained until the end of the retention
period even if subscribers have picked them up.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

A lil confused from BOL

These are 2 different things.
For (A) this is the length of time that transactions are
retained in MSrepl_commands before the cleanup agent can
remove them. If all subscribers have synchronized, the
commands are removed before this period. This is
different if you have anonymous subscribers of course.
For (B) this means that if a subscription doesn't
synchronize within the said period, it is marked as
inactive and must be reinitialized.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
So if (A) time is up.i.e. after 72 hrs , the cleanup agent would anyways
come in and delete all transactions hence making the subscription in a way
inactive and if you look at the publication properties, it has the 72 hrs
instead of the 336 hrs that (B) talks about..
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:0c5b01c4d917$3ba52390$a301280a@.phx.gbl...
> These are 2 different things.
> For (A) this is the length of time that transactions are
> retained in MSrepl_commands before the cleanup agent can
> remove them. If all subscribers have synchronized, the
> commands are removed before this period. This is
> different if you have anonymous subscribers of course.
> For (B) this means that if a subscription doesn't
> synchronize within the said period, it is marked as
> inactive and must be reinitialized.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>