- Related Stories
-
MySQL to get 'solid' transactions
April 16, 2006 -
MySQL fills Oracle-consumed hole in database
April 7, 2006 -
MySQL beefs up engineering with Firebird alum
February 24, 2006
The database engine, code-named Falcon and due for completion later this year, will be built specifically for running transactions, said Zack Urlocker, vice president of marketing at the company. A beta version is due out this summer, he said.
MySQL executives will detail Falcon and other upcoming tools at its user conference, which will take place Monday through Thursday in Santa Clara, Calif.
The company gained the beginnings of Falcon when it acquired Netfrastructure, a consulting company that employed database luminary Jim Starkey.
MySQL's database is built so that it can use a range of different storage mechanisms, tuned for different purposes, such as transactions or indexing large amounts of text.
"Rather than have one perfect engine, it's better to have a pluggable architecture," Urlocker said. "The idea is you can mix and match within a single application because data will be used in different ways."
He said that Falcon is being designed for "scale out" configurations, where an application, such as an e-commerce site, is powered by several, relatively low-priced servers, rather than a few, more powerful machines.
MySQL is expected to disclose the names of other software companies, including Solid Information Technology, that intend to write storage engines for the MySQL database.
Company executives also intend to show off MySQL Workbench, a graphical database design tool under development, which will be released under the open-source General Public License.
See more CNET content tagged:
MySQL,
database company,
database,
open source
Rows are not records; fields are not columns; tables are not files!!
http://joecelkothesqlapprentice.blogspot.com/
implementation of an ANSI standard SQL DBMS, is not restricted
to a vision of "Rows are not records, etc", in truth its, well,
wrong.
However, I was intrigued by this statement, so I decided to take
a look at your site. There is nothing wrong with pushing
yourself, but you must be careful about forming strong views,
that could be based on an assumption. I guess I'm saying its ok
to be wrong, just be aware that sometimes, especially within the
first five years of coding, when you think you're absolutely right
you can be absolutely wrong. Unfortunately, this "affliction"
occurrs throughout ones career, but with far less frequency with
experience.
So, instead of being critical, which is a good thing if you can
learn from it, I am including something for you to look at (in
reference to your link):
CREATE TABLE [Suburbs]
(
[id] INT IDENTITY(1, 1) PRIMARY KEY,
[suburb] VARCHAR(50) NOT NULL,
[state] VARCHAR(2) NOT NULL
)
GO
CREATE TABLE [Surrounds]
(
suburb_id INT REFERENCES [Suburbs]([id]) ON DELETE CASCADE,
[n_suburb_id] INT REFERENCES [Suburbs]([id]) ON DELETE NO
ACTION
)
GO
CREATE UNIQUE INDEX ucix ON [Surrounds]([suburb_id],
[n_suburb_id]) WITH IGNORE_DUP_KEY
GO