The power of written languages

This is at the heart of why I invented my String Theory of Databases. I was developing an invoicing program and wanted field labels and tooltips and even help files in other languages than English. So how would I switch? How would I have the user do this? ( Actually I found a way to capture their language in the database I’m using by looking at their default system language. )

It would have been very normal to simply create two or three copies of the database. One for each language. But that would require upkeep on three versions. Yes, there are other ways but all that I’ve seen are not very elegant in their approach.

I am getting a test database together to show you how it can be used for languages. In this very simple, yet powerful way, you can develop databases that are international. In the new way of defining tables and fields, you may find it an advantage to slowly build, say, the three top languages of your area into your solution. I have chosen English ( US ), Spanish ( Western ) and Chinese ( simplified ) as they are the top three [reference] languages in the United States of America.
All the best,
Brian

The core of my theory

I am Brian Ginn. I created the String Theory of Databases. Using a spreadsheet, I show you the core essence of my theory. It is all in the new naming conventions. As simple as this may seem, don’t stop watching the next few videos. This only opens the door to some amazing things.

Video String Theory of Databases 002 from Brian Ginn on Archive.org.

All the best,
Brian

Draft Video

[Narrative of video.] Hi, I am Brian Ginn and it is August 4th, 2008. I am here to explain the “String Theory of Databases” as I call it. What I am going to show you first is the history of databases as they are now.

This looks like a typical database. This is one like any other. But when you go to look at the fields of it what you see is human-readable fields. Some of them get a little tricky like these: ID, IDentity, CompanyIDentity ( what the heck is that? ) and IDcontact. This “ID” thing is very common in databases. It actually is what merges the databases so if we go to [look] at relationships we’ll see that IDcontact relates to IDcontant IDcontact ( in the schema of relationship joins ). That makes sense. And you got the field names down here ( referring to below the IDcontact above ). That’s the where database are now.

Video String Theory of Databases 001 from Brian Ginn on archive.org.

All the best,
Brian Ginn

P.S I shortened this video after your comment Sean. I simply clipped the video after my introduction to current database naming conventions.

The String Theory of Databases

I know it doesn’t make sense for you now. I know it won’t make any more sense after you read this first post. However, if you follow me as I explore it further, you too will see the great benefits to come. Things are going to get easier.

It took me a few years, but last week I proved my theory. Actually, I never started to prove my theory until last week. My theory is to use database field names just as DNA is coded. Start something simple and uniform and let it build into a its bigger self. Just as an organism is built from DNA, a advanced database can be built in the same way.

My challenge will be to make this theory available to all. My challenge will be to publish it in such a way here that you can understand me. My goal is for the betterment of human technological development. So I will journal about my adventure here. The adventure begins.

All the best,
Brian Ginn