|
|
Posted by Tony Rogerson on 11/12/06 08:48
You don't mention CHECK constraints on the email address - we are still
waiting for you to show us how you do that in a CHECK CONSTRAINT.
You seem to think you can make reference to other tables and call a stored
procedure from within a CHECK CONSTRAINT.
Are you going to finally admit you are wrong and that the only reasonable
way to validate an email address in a CHECK CONSTRAINT is CLR?
--
Tony Rogerson
SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL
Server Consultant
http://sqlserverfaq.com - free video tutorials
"--CELKO--" <jcelko212@earthlink.net> wrote in message
news:1163286964.503083.141330@h48g2000cwc.googlegroups.com...
>>> I am using email addresses as relational keys. each and every table has
>>> an email associated with each row. <<
>
> Good; make sure that you have ON DELETE/UPDATE CASCADE clauses on the
> referencing tables. m
>
>>> this is part of the profile owner's description. about_me is TEXT and
>>> describes the users background. interests, again TEXT, is more specific.
>>> <<
>
> Have you ever filled out a survey card that came with a consumer
> product? They often have a list of interests (travel, boating, movies,
> etc.) -- that is how you encode specific data like interest and not in
> free-form text.
>
>>> I am not sure if that is correct about the BIT values. The value
>>> indicates an action taken, such as a rejected or accepted request, and I
>>> dont see how else to do this. <<
>
> After 20+ years with SQL and RDBMS, I am sure. You are using
> low-level, highly proprietary data types. Give me the action and the
> date that the action was taken, not an assembly language style flag.
>
>>> or, i dont see the point to improving on this method. what is being
>>> harmed by this? <<
>
> Growth of the code, validation against the rest of the history and data
> loss.
>
>>> I like the idea of having an overall table for my profiles, as there are
>>> about 30 individual tables at this point that describe different
>>> features of the profile (EditProfile, AddList, PersonalPhotos, etc). I
>>> am not quite sure how to procede doing this. I'll do some reading on
>>> this, in the mean time; am i doing any harm by continuing to build my
>>> system the way i am? can the aggregate table be created at a later date
>>> without much reverse engineering? <<
>
> I cannot say; I have no specs. But 30 tables seems like a lot for a
> personal profile and perhaps a bit low for a full medical history.
> Instead of pushing ahead with a weak design and then trying to fix it,
> I would stop and spend the effort on getting it right at the start.
>
> There is the "cowboy coder" impluse to code something in two minutes
> with proprietary tricks and a short-term view of efficient architecture
> rather than take two days (or even two months!) to research standards
> and come up with a consistent, portable, verifiable design.
>
[Back to original message]
|