Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > microsoft.public.sqlserver.programming > #31347

Re: Storage of "Do Not Show This Again" Flags

Path csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From Erland Sommarskog <esquel@sommarskog.se>
Newsgroups microsoft.public.sqlserver.programming
Subject Re: Storage of "Do Not Show This Again" Flags
Date Tue, 05 Feb 2019 23:48:28 +0100
Organization Erland Sommarskog
Lines 32
Message-ID <XnsA9EDF22F918E0Yazorman@127.0.0.1> (permalink)
References <q3aq3m$qon$1@dont-email.me>
Mime-Version 1.0
Content-Type text/plain; charset=windows-1252
Content-Transfer-Encoding 8bit
Injection-Info reader02.eternal-september.org; posting-host="a1ea18d5d61e90f3b56963a64123bab3"; logging-data="13780"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/bMv8jdLmdCiv+klOJ+zA7"
User-Agent Xnews/2006.08.24 Mime-proxy/2.1.c.0 (Win32)
Cancel-Lock sha1:OaoKd+SHr2N80eLjLdgC7s4v9yQ=
Xref csiph.com microsoft.public.sqlserver.programming:31347

Show key headers only | View raw


Michael Cole (invalid@invalid.com) writes:
> For our application, we now want to introduce the concept of "Do Not 
> Show This Again" tickboxes on popup dialogs. I need to store and 
> retrieve these from the database. I am looking for suggestions on how 
> they should be stored.
> 
> The values will need to be stored against a user, for which we have a 
> foreign key. I will provide stored procs for accessing these values - 
> read and update. Options I had were: -
> 1. Single table, dual PK of Flag ID and User ID, with a single bit 
> field to hold the value - non-existance will be considered as false. We 
> could also have a string field to provide a description of what the 
> flag is.  Or perhaps better would be a linked table for the flag 
> definition.

I have not implemented something like this(*), but this appears as the 
obvious design to me. It is quite clear that new tickboxes will be 
added as your app evolves. Having a table with many bit columns,
means a lot of work when new flags are added.

I would make the table a two-column table: UserID and Flag. Unless 
there are som nuances that require more than two values, I see no 
reason for a bit column. Flag present => Flag set. Flpag absent => not 
set.

I would also have a lookup table for the flag definition, with an FK 
constraint to this table. This traps mispelled flag names. (I would
prefer to use codes rather than numeric ids.)

(*) OK, so I have made a table design exactly like this, but it 
nothing to do about checkboxes, but a lot of binary properties
on accounts.

Back to microsoft.public.sqlserver.programming | Previous | NextPrevious in thread | Find similar


Thread

Storage of "Do Not Show This Again" Flags Michael Cole <invalid@invalid.com> - 2019-02-05 12:49 +1100
  Re: Storage of "Do Not Show This Again" Flags Erland Sommarskog <esquel@sommarskog.se> - 2019-02-05 23:48 +0100

csiph-web