Subject- Introduction to Database design and Administration I need three factors
ID: 3766498 • Letter: S
Question
Subject- Introduction to Database design and Administration
I need three factors that influence the selection of data API, please state which these three factors are and provide a short explanation as I am needing to write a short essay on these factors and on options available (ODBC, OLE DB & SQL Native Client) . Please find reference material below (I have read and cannot figure out). Thanks.
Factor 1?
Factor 2?
Factor 3?
****Also please discuss options available:
ODBC-
OLE DB-
SQL Native Client-
376 DATA ACCESS AND SECURITY 11.1.2 Understanding Client/Server Connectivity In the traditional client/server model, you have two computer types involved These are the client that provides the interface with the user and the server that stores and maintains the database. Though the traditional model puts the appli cation on the database server, realistically it can reside just as easily on the client computers. In fact, that's the model used in most small-scale database applica tions. A copy of the application runs on each client PC and the client PCs share the database stored on a central database server 8711359 2015/11/28 173.168.113.135 The basic foundation for connectivity, including the communication path physical connection, and the basic communication protocol, are provided by the network. These are primarily the responsibility of network administrators (or a similar role) within your company. That doesn't mean that you don't have your own responsibilities as well. You might have protocol options available and have to configure protocol use at the server Most discussions about database design focus almost exclusively (at least ini tially) on the data. However, the data is useless if you dont have a way to access it Database connectivity, built on the foundation provided by the network, is a necessary part of your iinal design and a required component dunng impl mentation. The requirements for designing and configuring connectivity require ments are somewhat DBMS-specific, but there are some common factors that should be discussed. When looking at requirements specific to DBMS imple mentations, we'll use SQL Server 2005 as our example. Though the implemen tation details may be different with other DBMSs, the general concepts and requirements will be similar Understanding Connectivity Interfaces During database design and implementation, you will make final decisions about the communication path. Even though this is a function of the network on which the clients and server are deployed, there are DBMS-specific options that con- trol communication flow. After making these decisions, you have to determine which data application programming interface (API) you will use To understand the role of the data API, imagine yourself as a bicycle courier You've been called by one of General Hardware Companys customers. You need to pick up a package and deliver it to the customer. You arrive at General Hardware Company, identify yourself, identify the customer, and request the package Package in hand, you ride across town and deliver it to the customer Thats not unlike what happens in a communication session between a client and a server. The requirements for that session are also similar to the physical transfer. The client needs to identify itself to the server. In some configurations the server must also identify itself to the client through a process known as mutual authentication, The client needs to pass commands to the server and receive a response. Your first thought might be that this is all handled by theExplanation / Answer
SQL Server Native Client is one technology that you can use to access data in a SQL Server database.
When deciding whether to use SQL Server Native Client as the data access technology of your application, you should consider several factors.
1) For new applications, if you're using a managed programming language such as Microsoft Visual C# or Visual Basic, and you need to access the new features in SQL Server, you should use the .NET Framework Data Provider for SQL Server, which is part of the .NET Framework.
2) If you are developing a COM-based application and need to access the new features introduced in SQL Server, you should use SQL Server Native Client. If you don't need access to the new features of SQL Server, you can continue to use Windows Data Access Components (WDAC).
3) For existing OLE DB and ODBC applications, the primary issue is whether you need to access the new features of SQL Server. If you have a mature application that does not need the new features of SQL Server, you can continue to use WDAC. But if you do need to access those new features, such as the xml data type, you should use SQL Server Native Client.
Both SQL Server Native Client and MDAC support read committed transaction isolation using row versioning, but only SQL Server Native Client supports snapshot transaction isolation. (In programming terms, read committed transaction isolation with row versioning is the same as Read-Committed transaction.)