¿how to join a database with a website?

[g2001a65]

Hello friends, I'm new in the programming business and in the forum, and I'd be glad if you could help me. the question is, I have a database and a website, what can i do for join them?. I want that a visitor can check only a little bit of that database.

[jessicams16863]

Are you already using a scripting language on your site? What kind of database do you have? If you use something like PHP and MySQL, I would recommend using PDO (PHP Data Objects) to access and query that database.

The manual entry: http://php.net/manual/en/book.pdo.php

Here's a reasonable guide to getting it working:
http://www.kitebird.com/articles/php-pdo.html

If you want more specific help, you might want to be more specific about what you have so far.

[g2001a65]

Hello friends, I'm new in the programming business and in the forum, and I'd be glad if you could help me. the question is, I have a database and a website, what can i do for join them?. I want that a visitor can check only a little bit of that database.

I am designing a website, and I want that a visitor can choose only one option from a database that I've already have, this database is .xls.

thank you for your help. this forum is grate

[jessicams16863]

Well, an XLS is an Excel spreadsheet. An excel spreadsheet is not a "database" as programmers or web developers are used to using. For example, x10 supports PostGreSQL and MySQL. You access data from this software by creating tables in SQL, then querying them with SQL (structured query language).

A scripting language like PHP is really easy to deploy. It's as easy as writing some code and uploading it to an Apache server (like x10 uses) that uses PHP as a ".php" file. The PHP code would query that database for whatever data you want to be displayed.

There are other ways to go about it, if it's not for a complex application, you could convert your spreadsheet to HTML, for example. But, the solution you want depends on your needs. Either way, I am a programmer, so I only know a programmer's perspective. There might be someone here that knows some software that can automate this for you.

[essellar]

Actually, an Excel sheet can be a database. MS Excel is (or, rather, was) as direct feature-compatible competitor to Lotus 1-2-3, and the 1, 2 and 3 of Lotus 1-2-3 were "spreadsheet", "database" and "business graphics". The VLOOKUP function is part of Excel's database module. It's a common mistake to conflate "database" with "RDBMS"; not all databases are relational (and none of my favorites are, though I've gotten used to shoehorning fundamentally non-relational data into something like MySQL for low-end web development -- or worse, something like Oracle for enterprises that need to feel they're getting their money's worth out of their license).

That being said, the problem here is the database engine. In order to use an Excel sheet as a database adjunct to a web application, you need a runtime engine that can read and write Excel. That's not going to happen on free or low-cost shared web hosting on a LAMP (Linux, Apache, MySQL, PHP) stack. You need to move the data to a different database -- either MySQL or SQLlite (PostgreSQL isn't supported on free hosting here, though it is on paid plans). MySQL is probably the batter option, not because it's the best fit for your data, but because nearly everybody here is using it in one way or another so it's a lot easier to get help when you need it. (And there are a lot of books and websites that can offer additional help, though many of them are based on older versions, outdated methods and "cargo cult" programming techniques.)

The simplest way to do things would probably be to dump your Excel sheet to a CSV (comma-separated values) file and import it into MySQL. Simplest, but nowhere near best. You'll want to spend some time first designing the database (which, at this point, is probably nothing more than a single table). That means taking the time to figure out what data types each of the columns ought to contain, and determining the sizes needed to suit (integers, long integers, floating point numbers, text columns with a maximum length), which columns are (and which are not) allowed to be empty (or NULL), which are going to be used regularly for lookups (they should be indexed) and which are knowably unique for each entry (the primary key, and that may be something you need to impose on data that don't naturally contain unique values).

There is really far too much to cover in a general reply -- one could easily write a thousand-page book that just skims the surface (and many have). If you want any real help, then you need to make you question a lot more specific. What do the data look like? Where do you want to use them? How are you planning to determine what the user can see (is it based on a login, the time of day, day of the year, etc.)?

It's not just a matter of "hooking things up"; there's programming and database design involved.