July 28, 2008 at 4:01 am
On my way in to the office this morning, I have come up with a fun little game we can all play.
Its called SQL Brain and the idea is we all post potential tables/functions/views that could possibly store the same information as our brain!
For example:
CREATE TABLE [dbo].[Contacts](
[ID] [uniqueidentifier] NULL CONSTRAINT [DF_Table_1_FriendID] DEFAULT (newid()),
[Name] [varchar](50) COLLATE Latin1_General_CI_AS NULL,
[Tel] [varchar](15) COLLATE Latin1_General_CI_AS NULL,
[Mobile] [varchar](15) COLLATE Latin1_General_CI_AS NULL,
[Email] [varchar](15) COLLATE Latin1_General_CI_AS NULL,
[Type] [int] NULL
) ON [PRIMARY]
Just post another possible object for our SQL Brain! I dont think structure or naming conventions matter etc for this.
Matt
July 29, 2008 at 6:15 am
I'm not entirely sure I understand what your are suggesting, or why.
July 29, 2008 at 7:04 am
email 15 characters!
name 50 characters!
What planet are you from? planet n00b?
I take it this is not a serious thread 😀
Hiding under a desk from SSIS Implemenation Work :crazy:
July 30, 2008 at 1:44 am
not sure I understand either, but I like games lets play
July 30, 2008 at 2:13 am
Ooops, please forgive my poor coding above!
The idea was to simply design a sql database that could potentially store the same data as the brain. For example, in my first post i created a table called contacts. This would store the details and demographics for every person i know. Some people would have full details, some people might just have a name.
I just thought it might be fun to try and model the brain!
Matt
July 30, 2008 at 2:36 am
I don't keep contact details in my head,
but I do have a 1 through 12 instant lookup multiplcation matrix.
.i.e. give me any two integers 1 through 12 and I know what the product is without thinking about it 100% accurate.
Its like hardwired. 😀
Hiding under a desk from SSIS Implemenation Work :crazy:
July 30, 2008 at 9:18 am
hmmm... interesting concept. "SQL Brain". I wonder though, instead of storing facts, could we (if given infinite processor and infinite storage) create a database that mimics the structure and workings of the brain? Then scale it back?
As I understand it (and I am not by any means "educated" in this sense, just a geek who likes learning), the brain works by a chain of multiple neurons being fired, somewhat simultaneously, until a request or thought is returned. The more often a specifc memory or thought pattern is accessed, the stronger the neural connection. In other words, not only does learning effect what is in the brain, but also the access paths and physical structure of the brain.
So, from a database standpoint, how do we beign modeling this? What is our scope? The mind stores impressions, memories of images, colors, scents, touch, etc. It also stores numbers and words, shapes and sounds, "good" and "bad". My thought would be let's start with "good" and "bad", "true" and "false", "yes" and "no". We can call these "Impressions". Impressions are not good without facts, so we also would need a table called "Facts". Now, you need a way to process or relate different facts, so if we present our database with a red car either red or car or both is returned. Let's use that as the center of our "brain". A table relatin fact 1 to fact 2 with an impression and a strength (equivelant let's say to number of neuron connections). Let's also take it a step further and add a "temp table" of recent thought connections. That way, if we supply a blue balloon, then a yellow boat, and then provide the red car "Red" is more likely than "car". But, if we show a airplain, then a boat, and then the red car, "car" is the more likely. In both examples, more facts are needed, such as "Color" to "Red" and "Vehicle" to "Car". For tuning sake let's add another table that contains nothing but configuration values, such as how much information can be kept in the "temp" table at once, what threshold (minimum relative number of neurons) and what factor that threshold has for pulling in new facts into the temp table, as well as how many facts and what factor should be pulled in. Factor for number and minimum related threshold is used in case there is no solid relationship, or several things are related, what rule to use?
CREATE TABLE [Impression] (
ImpressionID INT
, SimplifiedLabel NVARCHAR(25)
)
CREATE TABLE [Fact] (
FactID BIGINT -- Lot's of facts possible!
, SimplifiedLabel NVARCHAR(500) -- limit length and complexity of a fact slightly...
)
CEATE TABLE [LongTermMemory] (
Fact1ID INT
, Fact2ID INT
, ImpressionID INT
, Strength Float
)
CREATE TABLE [ShortTermMemory] (
Fact1ID INT
, Fact2ID INT
, ImpressionID INT
, RelationStrength Float
, FrontOfTheBrainStrength Float
)
CREATE TABLE [BrainConfig] (
PersonID INT
, ShortTermMemorySize INT
, MinRelationStrength FLOAT
, RelationStrengthFactor FLOAT
, MaxRelationCount FLOAT
, RelationCountFactor FLOAT
)
CREATE PROC [QueryBrainImpression]
(DelimitedFactList NVARCHAR(MAX), ImpressionOrFact CHAR(1))
Returns NVARCHAR(500)-- Either an impression or a Fact simplified label
AS
BEGIN
...
END
CREATE PROC CleanShortTermMemory()
AS
BEGIN
...
END
The procedure QueryBrainImpression would be at the heart of it. It would need to translate the delimited fact list into a set of facts... every fact compared to every other fact. Then, all fact relations would need to be compared using first the ShortTermMemory table. If after the short term memory table the requirements of the facts to be loaded (or in this case reloaded) into the temp table, as identified by BrainConfig, is met, the relation strength is incremented using either a linear or a related algorythm. Either an impression or fact will be returned, based on what was asked. Also, CleanShortTermMemory will be called, which could potentially use a sperate algorythm and config settings to determine what should be added to long term and what should be "lost". Any new facts would need to be added with an initial relationship strength to any of the foremost (i.e. recently added) facts. Then these facts would be deleted, keeping the short term memory small.
Once this is running, it could be expanded to a full blown "AI" esq query system... and maybe to a true "SQL Brain".
July 30, 2008 at 9:33 am
Yeah and implement a couple of stored procs called blow_to_head and alchol_intoxication which use some sort of fuzzy logic and produce random loss of data and strange returns from select queries when triggered. 😀
Seriously though I like the facts concept! 🙂
Hiding under a desk from SSIS Implemenation Work :crazy:
July 30, 2008 at 9:41 am
Shaun McGuile (7/30/2008)
I don't keep contact details in my head,but I do have a 1 through 12 instant lookup multiplcation matrix.
.i.e. give me any two integers 1 through 12 and I know what the product is without thinking about it 100% accurate.
Its like hardwired. 😀
Heh we did this in school in Gibraltar when I was 4. They called it "Your taybulls" as in "Stand on your chair and do your taybulls, boy!"
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
July 30, 2008 at 9:46 am
We didn't have to recite it ever just had to know it instantly without singing "once one is one..." etc.
20 Sums in 20 Seconds was the test - less than 75% correct and you were in trouble.
you speak the numbers, my brain process the words, and i say the answer - instantly without saying anything else is how it works for me. 😀
Hiding under a desk from SSIS Implemenation Work :crazy:
July 30, 2008 at 11:51 am
I think my brain has lots of little tables, very little DRI, and way too many cross joins occurring on a regular basis.
July 30, 2008 at 4:07 pm
[/size][/size]Shaun McGuile posted:
Yeah and implement a couple of stored procs called blow_to_head and alchol_intoxication which use some sort of fuzzy logic and produce random loss of data and strange returns from select queries when triggered.
I think the game programmers at Nintendo could identify with this. I recall from years ago that Super Mario Bros on SNES had one level wherein touching a bubble (or dandilion -- I forget) made the world go woozy, rocking back and forth and more difficult in which to not slide off the platforms.
July 30, 2008 at 4:21 pm
MentalWhiteNoise (7/30/2008)
hmmm... interesting concept. "SQL Brain". I wonder though, instead of storing facts, could we (if given infinite processor and infinite storage) create a database that mimics the structure and workings of the brain? Then scale it back?
So... more like a manager's brain then?
🙂
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
July 30, 2008 at 7:33 pm
rbarryyoung (7/30/2008)
MentalWhiteNoise (7/30/2008)
hmmm... interesting concept. "SQL Brain". I wonder though, instead of storing facts, could we (if given infinite processor and infinite storage) create a database that mimics the structure and workings of the brain? Then scale it back?So... more like a manager's brain then?
🙂
lol. I didn't mean to scale it back that far... 😛
July 31, 2008 at 2:13 am
john.arnott (7/30/2008)
[/size][/size]Shaun McGuile posted:Yeah and implement a couple of stored procs called blow_to_head and alchol_intoxication which use some sort of fuzzy logic and produce random loss of data and strange returns from select queries when triggered.
I think the game programmers at Nintendo could identify with this. I recall from years ago that Super Mario Bros on SNES had one level wherein touching a bubble (or dandilion -- I forget) made the world go woozy, rocking back and forth and more difficult in which to not slide off the platforms.
That was Yoshi's Island ( I still own a SNES and the Game Cartridge) 😀
Hiding under a desk from SSIS Implemenation Work :crazy:
Viewing 15 posts - 1 through 15 (of 21 total)
You must be logged in to reply to this topic. Login to reply