Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

Relational Databases (MySQL)

Name: Anonymous 2010-06-02 18:48

I am making a search engine -- I need the engine to query multiple static tables (more than 2) and return a resource with the results.

This is not, I find, as simple as

...
FROM table1, table2, table3, ...
...

(afaik). I tried using JOIN but, unless I am doing it wrong, it is not the tool I'm looking for.

My idea is now to create a master global index (table) of all possible results with an attached id number -- searching this table would be easy. Then I'd JOIN this with every table, find the row with the matching id, and return results for that. (I'd have to JOIN it many times over with every table). This does not seem very elegant. In fact, my whole project is becoming less and less elegant as I discover more of SQL's limitations.

Ideas or pushes in the right direction would be appreciated.

Name: Anonymous 2010-06-02 18:53

For fuck's sake. These have to be deliberate trolls.

Name: Anonymous 2010-06-02 18:59

Check whether your database is plugged in (look for a green status indicator on the back side)

Name: Anonymous 2010-06-02 19:01

>>2
My copypasta search turned out negative.
Summer is here.

Name: Anonymous 2010-06-02 19:07

Well I guess the fact that /prog/ thinks I'm trolling is indicative that the solution is obvious. So in a round-about way I guess that helped. Thanks.

Name: Anonymous 2010-06-02 19:11

>>5
YHBT

Name: Anonymous 2010-06-02 19:12

>>1
as I discover more of SQL's limitations
Yeah, I bet the issue is SQL, and not the fact that you can't design a database for shit.

Name: Anonymous 2010-06-02 19:12

>>1
I find your problem:
Relational Databases (MySQL)
                      ^^^^^
Error in line 0: MySQL is not a relational database


It's not even a good implementation of what people call relational databases today.  There are so many good, free alternatives.

Name: Anonymous 2010-06-02 19:21

>>5
WE HELPED HIM :(

Name: Anonymous 2010-06-02 19:45

ISO/SQL is inherently flawed for use in a database.

As postgreSQL shows it is possible to implement the highest standard transaction isolation level correctly and still fuck up ACID

section 12.2.2.1. in
http://www.postgresql.org/docs/8.1/static/transaction-iso.html

(Appreciate the ``predicate locking'' sand-in-the-eyes part, actually they'd just need to not execute queries concurrently. That is slower but the alternative is incorrect results, see "Worse is Better")

Name: Anonymous 2010-06-02 20:07

>>10
see "Worse is Better"
Outside of academic circles known as "Good enough".

Name: Anonymous 2011-02-04 17:15


Don't change these.
Name: Email:
Entire Thread Thread List