Source language: Translate to:

New database plug-in needs a name

Questions about NeoBook PlugIns

Moderator: Neosoft Support

New database plug-in needs a name

Postby Neosoft Support » Thu May 24, 2007 11:14 am

Can you help us name our new baby?

As you know, we're working on a new professional database plug-in which should be ready for beta testing very soon. However, we're having trouble coming up with just the right name. Here are some things being considered:

NeoBookODBC
NeoBookADO
NeoBookDBPro

Keep in mind that the name (or its abbreviation) should also be suitable for use as a prefix for the plug-in's action commands. For example:

odbcOpenDatabase
adoOpenDatabase
dbpOpenDatabase

If you have any preferences or other ideas please feel free to post them here.

Thank you.
NeoSoft Support
Neosoft Support
NeoSoft Team
 
Posts: 5605
Joined: Thu Mar 31, 2005 10:48 pm
Location: Oregon, USA

Re: New database plug-in needs a name

Postby dpayer » Thu May 24, 2007 2:51 pm

Neosoft Support wrote:Can you help us name our new baby?

As you know, we're working on a new professional database plug-in which should be ready for beta testing very soon. However, we're having trouble coming up with just the right name. Here are some things being considered:

NeoBookODBC
NeoBookADO
NeoBookDBPro

.


This caused me to lookup some references so I know the difference between ODBC and ADO. I found this older one at Microsoft:

http://www.microsoft.com/technet/prodte ... schp7.mspx

and I will clip the most significant part below.

The interesting fact is that ADO is a superset of ODBC. To the degree it is the focus (vs. ODBC) I would name after it. Also if it has the scripting ability of ADO, I would focus on it.

Having said that, I think this is a uniquely NB expression of database connectivity so I think the DBPro name distinguishes it from the original DB plugin and in the application features you can describe its ADO/ODBC capabilities.

We all look forward to this!

David P.

Microsoft Data Access Components
The previous section discussed the benefits of providing database access solutions on the Web. This section discusses how you can develop these solutions using Microsoft data access technologies.

Universal Data Access is Microsoft's initiative for providing high-performance access to all types of information (including relational and nonrelational data) across an organization, from the desktop to the enterprise, using practically any tool or language.

In a parallel effort with the Microsoft® Windows® Distributed interNet Applications (Windows DNA) architecture, the Universal Data Access initiative is a platform, application, and tools strategy that defines and delivers standards and technologies essential for application development.

MDAC is comprised of the data access technologies that enable Universal Data Access: ODBC, OLE DB, and Microsoft® ActiveX® Data Objects (ADO). Figure 7.1 shows how these data access components interact. For the latest information and current releases of MDAC see http://www.microsoft.com/data.

Image

Figure 7.1 Microsoft Data Access Components

The next few sections describe each of the MDAC technologies. Most of your Web applications will use ADO, which is described in detail later.

ODBC and OLE DB
The ODBC standard is a widely recognized method of accessing data in a variety of relational databases. It is fast, lightweight, and provides a common method that is not optimized for any specific data source.

Like ODBC, OLE DB is an open specification. It was designed to build on the success of ODBC by providing another standard for accessing data. Whereas ODBC was created to access relational databases, OLE DB interfaces are designed to communicate with any data source including relational and nonrelational data, such as Microsoft® Excel spreadsheets, as well as e-mail, and text files. There is no restriction on the type of data you can access with OLE DB-relational databases, indexed sequential access method (ISAM), text, or hierarchical data sources.

OLE DB is set of programming interfaces designed for driver vendors who want to expose a data source, and for C++ developers wanting to develop custom data components. Microsoft® Visual Basic®, which does not support Automation objects, cannot use OLE DB directly.

Applications that use OLE DB fall into two categories: consumers and providers. A consumer application uses (or consumes) data through the OLE DB interfaces or components. A provider is any component or data source that allows consumers to access data in a uniform way through the OLE DB interfaces. In a sense, an OLE DB provider is similar to an ODBC driver that provides a uniform mechanism for accessing relational data.

Several OLE DB providers are available, including the Microsoft® ODBC provider, which exposes any ODBC-compliant database through OLE DB. Developers can implement an OLE DB provider for whatever data access they require, if one does not already exist.

ADO and RDS
ADO and Remote Data Service (RDS) use OLE DB providers to communicate with local and remote data sources respectively. Any application that uses ADO objects gets its data indirectly from OLE DB. If there is an OLE DB provider for it, the data is accessible through ADO.

You can use ADO to write both server-side and client-side applications that can access and manipulate data. ADO, designed to provide a universal high-level data access method, is a collection of Automation objects that can retrieve, update, and create records from any OLE DB provider.

ADO exposes a set of functions that all data sources are expected to implement. Using these core functions, ADO can access the unique features of specific data sources through OLE DB. Additionally, unlike earlier data access methods, you no longer need to navigate through a hierarchy to create objects. You can create most ADO objects independently and reuse them in different contexts. If used correctly, the result is fewer ADO object calls and a smaller working set.

There's a downside to all this flexibility, however. Because ADO is an OLE DB consumer, the peculiarities of the OLE DB provider that you are using directly influence the behavior of ADO. Just because you can write an application in ADO doesn't mean that the provider will support it. Often, ADO errors are a direct result of performing operations not supported by the OLE DB provider, or the underlying data source. As you develop database access components and applications, keep in mind that there are sometimes multiple ways to perform any given action.

RDS is a feature of ADO that facilitates client-side programming by optimizing the transfer of data between the client and the ADO components in the middle tier of a Web application. RDS uses ADO as a programming interface between the code and the data exposed by the underlying OLE DB provider. The client-side components of RDS are Microsoft® ActiveX® controls that use either Microsoft® Component Object Model (COM) components or Hypertext Transfer Protocol (HTTP) to communicate with the server components. Microsoft® Internet Explorer includes the RDS client-side components.

Note: For Microsoft® Internet Explorer 3.x users, MDAC 2.0 provides service components that are compatible with RDS server-side and client-side components. Client-side components are included with Microsoft® Internet Explorer 5. Since later versions of MDAC are not 100 percent compatible with earlier versions of the browser, you might need to upgrade your clients before using the more advanced features of RDS and ADO.

A detailed look at RDS and ADO is included in the section "Client-Side Data Access" later in this chapter.

Other Data Access Methods
In today's fast-paced technological arena, it is not surprising to find that last year's good idea is this year's outdated software. For the sake of those that cannot throw away older technology just to adopt the latest craze, the following section enumerates some older data access technologies that are still supported by IIS 5.0. However, unless you have a good business reason to use them, you should rely on ADO instead. ADO is designed to balance flexibility with programmatic simplicity. In most cases, it is the only data access method you will need.

ADC
The Advanced Data Connector (ADC) can be considered the parent of RDS. In fact, the RDS technology used to access remote data is inherited directly from ADC. The early design of ADC was less flexible than the ADO programming model, so it was integrated with ADO to provide a uniform means of accessing remote data. ADC itself is now considered obsolete; RDS (and ADO, which is used by RDS in the middle tier) has replaced ADC programming.

Instead of ADC, use RDS when you need to provide a common programming model for accessing either local or remote data. RDS objects are installed with Microsoft® Internet Explorer 4.0 and Internet Explorer 5 on your client, or you can download them at run time from the .cab files shipped with MDAC components.

Jet Database Engine and DAO
The Jet database engine is a workstation-based storage system. Jet databases can be accessed using Data Access Objects (DAO). You can also access Jet databases with the ODBC drivers provided with Access, but only limited functionality is exposed using these drivers. The Jet database engine has its own query and result-set processors and is capable of executing queries against homogeneous or heterogeneous data sources. Developers who are familiar with DAO can use ODBCDirect to bypass the Jet database engine when connecting to back-end data sources.

DAO requires that you change programming models depending on whether your data is stored in a Jet database or some other data store. ADO provides a common programming model for Jet databases or any other OLE DB data source.

RDO
The Remote Data Objects (RDO) were specifically designed to access remote ODBC relational data sources, and to add a thin object layer to the ODBC application programming interface (API). RDO performance is, in most cases, close to that of the ODBC API.

RDO was specifically designed to deal with remote, intelligent data sources (such as SQL Server or Oracle, as opposed to ISAM databases), so it does not support some of the DAO table-based interfaces or Dynamic Data Exchange (DDE). RDO can execute ordinary table-based queries, but it is especially adept at building and executing queries against stored procedures. It also handles all types of result sets including those generated by multiple result set procedures, those returning output arguments, and those requiring complex input parameters. RDO 2.0 provides a high level of control over remote data sources, so it is not necessary to expose the underlying ODBC handles in order to manipulate the data sources, except in the most unusual cases. It also can create client cursors to manage "disconnected" result sets.

Once again, newer technologies have surpassed older ones. For example, ADO provides equivalent functionality and performance to RDO, with an easier-to-use object model; ADO can also access a much larger variety of data stores.

The Cost of Data Access
Technology, like MDAC, comes with a price.

Suppose you're creating a site that publishes bus schedules for more than a hundred routes. The "static" solution might be an index page-perhaps with an HTML form-that allows the user to select and view route-specific pages. The "dynamic" solution might use a query page to look up each bus schedule as it is requested, and return it on a customized, dynamic page.

Both approaches offer the same solution, but the "static" one offers better performance, for two reasons:

• Delivering a static page demands far less processing than creating the same page on the fly.

• The static page solution creates each page once; the dynamic page solution might create a new page for each request (depending on how the server's cache is utilized) for information that generally doesn't change much.


Consider how your data will typically be used. Often a static approach is best for static data (such as bus schedules), and a dynamic one is generally best for dynamic data (such as stock quotes). However, the best solution is to provide a controlled mix of static and dynamic pages, as your users require them, that your site can support. For example, if people need infrequent access to large amounts of data, the best solution may be the dynamic approach: a query page. But if they can read a relatively short list of articles while online, it's better to generate the page once and display a static listing.

Once you've determined that the dynamic approach is necessary, choosing a data access method is based on what your application requires in the following areas:

• Performance

• Ease of development

• Ease of maintenance

• Ease of deployment


The emphasis you place on each factor should be motivated by both the current and future needs of your application. Given the robust growth patterns of the Web in recent years, application performance and scalability should be your foremost goals. It is important to note, however, that throughput numbers should in no way dictate your choice of technology. For example, although the cost of developing an ADO application can be significantly less than with ODBC, the number of transactions ADO can process per second (TPS) is significantly lower than what ODBC can achieve. If both ADO and ODBC exceed your target TPS, your decision on which technology to use should be based on factors other than performance.

Table 7.1 compares the TPS results of similar tests performed with each data access technology. For these tests, Component Services (implemented in Microsoft® Visual C++®) and connection pooling were used. The SQL Server database was scaled to 800 TPS, with 384 megabytes (MB) RAM, and 4 percent procedure cache.

Table 7.1 TPS Per Number of Threads by MDAC Technology


Image
The results of using relational data are striking (the comparison is not valid if the data is not relational). The ODBC component produced the highest throughput (as much as 277 percent higher than ADO using 50 threads). All data access technologies increased in throughput up to approximately 20 threads, after which performance dropped off.

These test results make the cost of data access very clear. If you use data access frivolously, you will be plagued with excessive delays and bottlenecks as pages are generated over and over again, and as transactions are processed for thousands of concurrent requests. By using the right data access methodology, and judiciously choosing when to generate dynamic pages, you can enhance and complement the static elements of your site.

User avatar
dpayer
 
Posts: 1384
Joined: Mon Apr 11, 2005 5:55 am
Location: Iowa - USA

Thinking about new baby

Postby carlos torres » Thu May 24, 2007 5:13 pm

Hi... walking around the references of MSAccess is a good one but hen you think about a prefix I will vote/suggest for a short form like DBO (Data Base Object)

regards

carlost
User avatar
carlos torres
 
Posts: 289
Joined: Mon May 02, 2005 8:14 am
Location: Pamplona, Colombia

Postby Cipolla » Fri May 25, 2007 1:17 am

Well, will the "old" NeoBookDB plugin still be available for download and use? if this is true my vote is for "NeoBookDBPro".

I think it would be a could idea to keep both plugins available because there are some situations where someone only needs a "small" but easy to use database and would use the normal plugin.

This is also a good start for newbees in working with databases to use the "Basic" plugin for the first steps.

Don´t lough, but what about renaming also the old one to "NeoBookDBBasic" ?
Greetings from Germany
Klaus
User avatar
Cipolla
 
Posts: 166
Joined: Fri Apr 01, 2005 1:45 am
Location: Germany

Postby dbz » Fri May 25, 2007 5:25 am

NeobookDBPro
User avatar
dbz
 
Posts: 42
Joined: Mon Apr 04, 2005 4:12 am
Location: Varel, Germany

Postby Boo (Gulf Breeze) » Fri May 25, 2007 8:20 am

NeobookDBPro is my vote, too.
User avatar
Boo (Gulf Breeze)
 
Posts: 99
Joined: Sun May 01, 2005 7:37 am
Location: Gulf Breeze, Florida

Postby lesanchss » Fri May 25, 2007 9:03 am

Hi friends,

It is really good to heard about the next release of the " to much waiting and dessire" database plugin from David.

My vote is for NeobookDBPro or NeobookDBPlus.

Thanks David for your great support.

Lesanch.
Todos somos ignorantes, solo que no todos ignoramos las mismas cosas.
Albert Einstein.
.
. .
User avatar
lesanchss
 
Posts: 24
Joined: Wed Sep 20, 2006 12:38 pm
Location: Cuba

Postby Gaev » Fri May 25, 2007 9:43 am

Thinking out aloud ...

Initial preference was for associating it with ODBC ... but odbcXXXX felt a bit too long ... 3 letter prefixes seem better ... odbXXXX ?

NeoBookDBPro might confuse some future new visitors into thinking there was a "seemless upgrade" from current NeoBookDB ... and I don't think/know that current pubs developed with NeoBookDB can deploy new plugin without making command changes.

After reading David P's post, agree that ...
I think this is a uniquely NB expression of database connectivity so I think the DBPro name distinguishes it from the original DB plugin and in the application features you can describe its ADO/ODBC capabilities
... so back to NeoBookDBPro (and dbpXXXX).


<@Klaus>

Well, will the "old" NeoBookDB plugin still be available for download and use?
... there would be no reason to not make it available ... although, as Dave has indicated recently, future enhancements would not be as frequent as in the past.

Don´t lough, but what about renaming also the old one to "NeoBookDBBasic" ?
... I hope NOT ... unless you are also going to change all references on this forum (and others) ... so we don't get an endless stream of questions from future developers asking what happened to NeoBookDB ? ... besides, most people don't like to be remined that they are working with something "very basic" ... if you can describe NeoBookDB as "basic".

So, my final choice would be NeoBookDBPro ... unless you prefer the command prefix "awty" ... in honour of all those developers posting "Are We There Yet ?" queries on this forum ... or "wwiba" (when will it be available) ... :-)
User avatar
Gaev
 
Posts: 3738
Joined: Fri Apr 01, 2005 7:48 am
Location: Toronto, Canada

Postby Neosoft Support » Fri May 25, 2007 11:17 am

Thanks for your input.

It sounds like NeoBookDBPro is the consensus choice. Now, what should we use for the command prefix dbpro or dbp? For example:

dbproOpenDatabase

or

dbpOpenDatabase
NeoSoft Support
Neosoft Support
NeoSoft Team
 
Posts: 5605
Joined: Thu Mar 31, 2005 10:48 pm
Location: Oregon, USA

Postby eddy current » Fri May 25, 2007 12:18 pm

Yes, NeoBookDBPro as the name and dbp as the prefix. I like the three-letter prefixes, like strFirstName and lngWindow, so dbp seems preferable.

Glen
eddy current
 
Posts: 48
Joined: Mon May 23, 2005 7:24 pm

NeoDBpro

Postby Luiz Alfredo » Fri May 25, 2007 12:21 pm

May vote for simple name:

NeoDBpro

or

NeoMDC (MultiDatabaseConnection)


Best Regards.

Luiz Menezes
L.A.G.M.
Luiz Alfredo
 
Posts: 195
Joined: Thu Apr 19, 2007 6:58 am
Location: Brazil

Postby TMcD » Fri May 25, 2007 2:59 pm

Although I seem to be late :P , I too like:

NeoBookDBPro

Troy
TMcD
 
Posts: 237
Joined: Sun Apr 10, 2005 11:20 am

Postby dpayer » Fri May 25, 2007 3:08 pm

Neosoft Support wrote:Thanks for your input.

It sounds like NeoBookDBPro is the consensus choice. Now, what should we use for the command prefix dbpro or dbp? For example:

dbproOpenDatabase

or

dbpOpenDatabase


I would be honored if you choose my initials to lable your database module but dbPro may be more clear to people. DB is clearly a reference to database, P is a reference to Payer... wait, no, I mean, it it ought to be more definitive. :lol:

DBP
David Brian Payer
User avatar
dpayer
 
Posts: 1384
Joined: Mon Apr 11, 2005 5:55 am
Location: Iowa - USA

Postby lesanchss » Fri May 25, 2007 6:02 pm

Hi All,

In my modest opinion i think that "dbp" must be the prefix to use. it is short and clear to use. Like David said "dbpOpenDatabase" is a good option.

Regards,
Lesanch.
Todos somos ignorantes, solo que no todos ignoramos las mismas cosas.
Albert Einstein.
.
. .
User avatar
lesanchss
 
Posts: 24
Joined: Wed Sep 20, 2006 12:38 pm
Location: Cuba

Next

Return to PlugIn Discussions

Who is online

Users browsing this forum: No registered users and 1 guest

cron