Re: [postgis-users] Search Engine
+1 for triggers. It's always the best way to solve these situations, be it GIS or not. Bèrto On 4 August 2010 11:55, uli mueller uli.muel...@gmx.ch wrote: Ricardo, Clearly, if you want to search across different tables you need a way to combine data in a common place. You should not do anything like search the tables one after the other and combine the results. Even if you merge all tables into one, you will need some explicit mechanism (trigger!) to keep your tsvector up to date. Using inheritance? I would not see inheritance as a real goodie with PostgreSQL. There are some serious caveats that may cause more problems than inheritance can solve. Check the last paragraph in the docs on inheritance (http://www.postgresql.org/docs/8.4/interactive/ddl-inherit.html). A system using triggers to build the tsvector is not so hard to maintain. Once you have written the triggers it simply runs and runs. Any time data in any relevant table changes, a trigger updates the tsvector, some key (gid or whatever) and maybe other data like bounding boxes in the one and only table that will be searched. Some challenge could arise, if it takes too long to rebuild your index on the tsvector. But normally this is not critical. We use the trigger approach for our search engine on http://mapmatters.org . The hardest thing there was and still is to optimize the way how data are combined and weighted for the tsvector ( so how you feed the to_tsvector function). Uli Am 04.08.2010 00:33, schrieb Ricardo Bayley: Hi fellows, I am creating a search engine for my spatial data. And I am thinking of the best approach. My idea is to have a full text search (tsvector) coulmn for every table. Instead of performing a search on every table, I have thought of a few options 1. Merge all tables into one, regardless of their geometry type. 2. Use PostgreSQL goodies such as table Inheritance to split geometry types. (not sure if it would be of any good) 3. Create a table to store table oid, gid and full text search data of every table in my system, and query this table instead. This should be harder to maintain, since it should be done through triggers and rules. Hope I explained it clearly. By the way, at start I only have 20 tables, with not more than 500k rows total. So it is not much, but this should grow considerably. Do you guys have any thoughts on this ? Looking foward to hearing from you. Ricardo ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users -- geOps GeoInformatics www.geOps.de D-79098 Freiburg ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users -- == Constitution du 24 juin 1793 - Article 35. - Quand le gouvernement viole les droits du peuple, l'insurrection est, pour le peuple et pour chaque portion du peuple, le plus sacré des droits et le plus indispensable des devoirs. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Search Engine
Uli, Clearly, if you want to search across different tables you need a way to combine data in a common place. You should not do anything like search the tables one after the other and combine the results. There may be a software limitation in PostgreSQL that supports this as a technical decision but it is foolish to suggest that you should not do anything like search tables one after another. Hell, I did just this in SQL Server 2008 with 800 tables and the execution of the FULLTEXT SQL is very, very fast. That is 10 seconds. I filter the tables by MBR first against an enhanced Geometry_Columns table before using FULLTEXT to do the search. But it may mean that you mean selecting against the tables using ordinary SQL with all searchable columns in the where clause as predicates. Yes, this would be very slow and inflexible in terms of search capability. That is why specialist search structures and functionalty have been created for most databases. Even if you merge all tables into one, you will need some explicit mechanism (trigger!) to keep your tsvector up to date. Correct. This is one of the reasons why this approach is unsustainable. Also, what if someone didn't have the ability to modify the schema at will? It might be that a lot of the use of PostGIS is as a shapefile replacement, but real application databases do not afford that sort of happy go lucky approach to data structuring. A system using triggers to build the tsvector is not so hard to maintain. Once you have written the triggers it simply runs and runs. Any time data in any relevant table changes, a trigger updates the tsvector, some key (gid or whatever) and maybe other data like bounding boxes in the one and only table that will be searched. Some challenge could arise, if it takes too long to rebuild your index on the tsvector. But normally this is not critical. We use the trigger approach for our search engine on http://mapmatters.org . The hardest thing there was and still is to optimize the way how data are combined and weighted for the tsvector ( so how you feed the to_tsvector function). I do not know much about tsvector but if you can create it external to the data and populate it by triggers without otherwise changing the data structures of the database then this would be a good solution. In SQL Server 2008 FULLTEXT's indexing of tables as they change can be declaratively organised. But if this is not possible with tsvector then the use of triggers may be the way to go. regards Simon -- SpatialDB Advice and Design, Solutions Architecture and Programming, Oracle Database 10g Administrator Certified Associate; Oracle Database 10g SQL Certified Professional Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE, Manifold GIS, FME, Radius Topology and Studio Specialist. 39 Cliff View Drive, Allens Rivulet, 7150, Tasmania, Australia. Website: www.spatialdbadvisor.com Email: si...@spatialdbadvisor.com Voice: +61 362 396397 Mobile: +61 418 396391 Skype: sggreener Longitude: 147.20515 (147° 12' 18 E) Latitude: -43.01530 (43° 00' 55 S) GeoHash: r22em9r98wg NAC:W80CK 7SWP3 ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Backup and Restore of a PostGis database
Thanks for all the answers so far, the suggestion to export only the relevant schemas seems to me the most viable; I'll try that and report back. To Brent's question: the problem is that the restore fails once it encounters an error, no objects are created. Thank you, Luís On Wed, Aug 4, 2010 at 7:56 PM, pcr...@pcreso.com wrote: Hi Luis, With option 2, all the errors are about a failure to create objects (postgis functions spatial_ref_sys entries I assume). Why is this a problem for you? ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Search Engine
Simon, we should not drift too far into a discussion about how you would do it with SQL Server. This was not Ricardos question. But I admit I have to specify some of my comments to get clearer. decision but it is foolish to suggest that you should not do anything like search tables one after another. Hell, I did just this in SQL Server The point ist not only speed. The main reason is that you loose the ability of PostgreSQL's full text search capabilitites to rank your results. With separate tables you have to pick the n best matches of each table and combine them afterwards to display the overall n best matches. Perhaps another way would be to join the tables in a view and do the search on the view. But then you can't fully benefit from the index. I don't know if SQL Server does not face these limitations? Anyway, 10 seconds is not really really fast - at least for a PostgreSQL database ;-) http://mapmatters.org . The hardest thing there was and still is to optimize the way how data are combined and weighted for the tsvector I didn't mean anything technical but the problem, how to produce the most meaningful results and ranking of the results (how to weight values out of different fields, which words are relevant or only stop words...). Uli -- geOps www.geOps.de D-79098 Freiburg Am 05.08.2010 10:01, schrieb Simon Greener: Uli, Clearly, if you want to search across different tables you need a way to combine data in a common place. You should not do anything like search the tables one after the other and combine the results. There may be a software limitation in PostgreSQL that supports this as a technical decision but it is foolish to suggest that you should not do anything like search tables one after another. Hell, I did just this in SQL Server 2008 with 800 tables and the execution of the FULLTEXT SQL is very, very fast. That is 10 seconds. I filter the tables by MBR first against an enhanced Geometry_Columns table before using FULLTEXT to do the search. But it may mean that you mean selecting against the tables using ordinary SQL with all searchable columns in the where clause as predicates. Yes, this would be very slow and inflexible in terms of search capability. That is why specialist search structures and functionalty have been created for most databases. Even if you merge all tables into one, you will need some explicit mechanism (trigger!) to keep your tsvector up to date. Correct. This is one of the reasons why this approach is unsustainable. Also, what if someone didn't have the ability to modify the schema at will? It might be that a lot of the use of PostGIS is as a shapefile replacement, but real application databases do not afford that sort of happy go lucky approach to data structuring. A system using triggers to build the tsvector is not so hard to maintain. Once you have written the triggers it simply runs and runs. Any time data in any relevant table changes, a trigger updates the tsvector, some key (gid or whatever) and maybe other data like bounding boxes in the one and only table that will be searched. Some challenge could arise, if it takes too long to rebuild your index on the tsvector. But normally this is not critical. We use the trigger approach for our search engine on http://mapmatters.org . The hardest thing there was and still is to optimize the way how data are combined and weighted for the tsvector ( so how you feed the to_tsvector function). I do not know much about tsvector but if you can create it external to the data and populate it by triggers without otherwise changing the data structures of the database then this would be a good solution. In SQL Server 2008 FULLTEXT's indexing of tables as they change can be declaratively organised. But if this is not possible with tsvector then the use of triggers may be the way to go. regards Simon ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] postgres data tables package (ORACLE Forms replacement?)
Brief background: We're currently using Oracle for our main database. Nothing too big, 15 - 20 tables and the largest table has about 100K records. We use Oracle Forms as a web-based option for inserting and updating records. I am using Postgres/PostGIS for a couple of other projects. I would like to use Postgres for our main database as well. However, I would need to come up with a solution for inserting/updating the data tables within our group (a replacement for Oracle Forms). Preferably, a web-based solution (PHP, Python, etc...) but it could be a Windows desktop solution installed on each staff members machine. Something that maintains the data integrity (e.g., forcing users to enter a date when Date is required, etc...) Does anyone know of a FOSS package that can be used to manage data tables within a Postgres database? Updating data records is the highest priority since the built-in Admin tool can be used for managing users, creating new tables, etc..., and will be done only by a database manager. Thanks for any advice or guidance you can provide. - John ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] postgres data tables package (ORACLE Forms replacement?)
Hi John, For the desktop, the best I've seen is MS Access, but it is certainly not FOSS. It is well used, documented, supported, easy form development, etc. A runner up is OpenOffice.org, but I haven't been able to develop too much on it, because I run into odd GUI behaviours that are deal-breakers (e.g., the scroll-wheel of the mouse can accentually modify numeric data if it hovers over a numeric field ... although this is in the process of being fixed). Kexi (from KOffice) is yet another app, but I haven't looked at it in a few years and I don't know if it is available for Windows anymore. For the web, there is WaveMaker, which is very web 2.0 with lots of JavaScript to make it appear like a desktop application. I've only had limited work with it, so I can't say too much about it. (I recall having a poor impression due to problems with bad permission assumptions and some other data type issues). There are others out there, but I'm interested to see what other people use. -Mike On 5 August 2010 06:53, John Callahan john.calla...@udel.edu wrote: Brief background: We're currently using Oracle for our main database. Nothing too big, 15 - 20 tables and the largest table has about 100K records. We use Oracle Forms as a web-based option for inserting and updating records. I am using Postgres/PostGIS for a couple of other projects. I would like to use Postgres for our main database as well. However, I would need to come up with a solution for inserting/updating the data tables within our group (a replacement for Oracle Forms). Preferably, a web-based solution (PHP, Python, etc...) but it could be a Windows desktop solution installed on each staff members machine. Something that maintains the data integrity (e.g., forcing users to enter a date when Date is required, etc...) Does anyone know of a FOSS package that can be used to manage data tables within a Postgres database? Updating data records is the highest priority since the built-in Admin tool can be used for managing users, creating new tables, etc..., and will be done only by a database manager. Thanks for any advice or guidance you can provide. - John ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] postgres data tables package (ORACLE Forms replacement?)
Hi John, OpenOffice is ok if you do not use views, you can create neat forms and there's also the option to edit data in tabular displays. Reports are also handy. But if you use views, OpenOffice simply don't deal with them. Best of luck, Luís On Thu, Aug 5, 2010 at 2:53 PM, John Callahan john.calla...@udel.edu wrote: Brief background: We're currently using Oracle for our main database. Nothing too big, 15 - 20 tables and the largest table has about 100K records. We use Oracle Forms as a web-based option for inserting and updating records. I am using Postgres/PostGIS for a couple of other projects. I would like to use Postgres for our main database as well. However, I would need to come up with a solution for inserting/updating the data tables within our group (a replacement for Oracle Forms). Preferably, a web-based solution (PHP, Python, etc...) but it could be a Windows desktop solution installed on each staff members machine. Something that maintains the data integrity (e.g., forcing users to enter a date when Date is required, etc...) Does anyone know of a FOSS package that can be used to manage data tables within a Postgres database? Updating data records is the highest priority since the built-in Admin tool can be used for managing users, creating new tables, etc..., and will be done only by a database manager. Thanks for any advice or guidance you can provide. - John ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] how delete null value
how to delete null values in table for geometry column ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] how delete null value
On Thu, 2010-08-05 at 07:53 -0700, Akhilesh Gan wrote: how to delete null values in table for geometry column Do you want to delete the complete record or just avoid the null? If the later, I think NOT NULL constraint will do just fine. If you want to delete the record its very easy. DELETE from table_name WHERE geometry_column IS NULL; -- Fabio R. Panettieri Software Architect http://www.xoomcode.com ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] PostGIS PHP setup on Windows 7
I'm not configuring PHP to work with PostGIS. So, when I try in PHP: require_once 'postgresqlConnect.php'; //make a connection to the database pg_query(CREATE TABLE polygon_test (p1 st_geometry)); I get: *Warning*: pg_query() [function.pg-queryhttp://localhost/processDatabase/function.pg-query]: Query failed: ERROR: type st_geometry does not exist LINE 1: CREATE TABLE polygon_test (p1 st_geometry) ^ in*C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\processDatabase\fillPostgresTable.php* on line * 51* * * *I can use PgAdminIII and use st_geometry. With PHP I've added the PostgreSQL bits so I can access the database.* * * *What I'm missing is the bits I've got to add to php.ini extensions. There are probably some PostGIS dlls that I'm missing as well to make PHP happy.* * * *If someone could point me in the right direction for getting PHP to work with PostGIS, I'd appreciate it.* ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] postgres data tables package (ORACLE Formsreplacement?)
John, For the web solution I use WaveMaker with but haven't done anything too fancy with it yet. http://www.wavemaker.com/ SQL Workbench might be another option. http://www.sql-workbench.net/ Eric Eric Randall GIS DB Admin/Analyst County of Erie 140 W 6th St Room 111 Erie, PA 16501 ph. 814-451-6063 fx. 814-451-7000 -Original Message- From: postgis-users-boun...@postgis.refractions.net [mailto:postgis-users-boun...@postgis.refractions.net]on Behalf Of John Callahan Sent: Thursday, August 05, 2010 9:54 AM To: PostGIS Users Discussion Subject: [postgis-users] postgres data tables package (ORACLE Formsreplacement?) Brief background: We're currently using Oracle for our main database. Nothing too big, 15 - 20 tables and the largest table has about 100K records. We use Oracle Forms as a web-based option for inserting and updating records. I am using Postgres/PostGIS for a couple of other projects. I would like to use Postgres for our main database as well. However, I would need to come up with a solution for inserting/updating the data tables within our group (a replacement for Oracle Forms). Preferably, a web-based solution (PHP, Python, etc...) but it could be a Windows desktop solution installed on each staff members machine. Something that maintains the data integrity (e.g., forcing users to enter a date when Date is required, etc...) Does anyone know of a FOSS package that can be used to manage data tables within a Postgres database? Updating data records is the highest priority since the built-in Admin tool can be used for managing users, creating new tables, etc..., and will be done only by a database manager. Thanks for any advice or guidance you can provide. - John ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] PostGIS PHP setup on Windows 7
Are you sure you are suing PostGIS? PostGIS geometry type is just geometry. I believe ESRI PostgreSQL SDE calls their datatype sde.st_geometry which seems closer to what you are trying to do there. So your query for PostGIS should be just CREATE TABLE polygon_test (p1 geometry); We use PostGIS in PHP and we don't use any additional dlls aside from the postgresql one. Leo and Regina, http://www.postgis.us _ From: postgis-users-boun...@postgis.refractions.net [mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of Jim Smith Sent: Thursday, August 05, 2010 12:36 PM To: postgis-users@postgis.refractions.net Subject: [postgis-users] PostGIS PHP setup on Windows 7 I'm not configuring PHP to work with PostGIS. So, when I try in PHP: require_once 'postgresqlConnect.php'; //make a connection to the database pg_query(CREATE TABLE polygon_test (p1 st_geometry)); I get: Warning: pg_query() [function.pg-query http://localhost/processDatabase/function.pg-query ]: Query failed: ERROR: type st_geometry does not exist LINE 1: CREATE TABLE polygon_test (p1 st_geometry) ^ inC:\Program Files\Apache Software Foundation\Apache2.2\htdocs\processDatabase\fillPostgresTable.php on line 51 I can use PgAdminIII and use st_geometry. With PHP I've added the PostgreSQL bits so I can access the database. What I'm missing is the bits I've got to add to php.ini extensions. There are probably some PostGIS dlls that I'm missing as well to make PHP happy. If someone could point me in the right direction for getting PHP to work with PostGIS, I'd appreciate it. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Search Engine
Uli, There are built in trigger functions for tsearch. We have some articles on the topic here - look at the cheat sheet for some examples of trigger use. http://www.postgresonline.com/journal/categories/30-tsearch There are a lot of ways to do this. You could get by with just a functional index on the relevant text tables and not need to store the tvector and just have a View for the tsvector. The savings there is that updates will be less taxing, but searches may be slightly slower depending on which index you opt for gin/gist since the false positives would have to be reinspected (similar to how geometry gist works) You could use table inheritance as well and just make sure the fulltext field is named the same across all your tables. That would prevent you the need of having to create a side table. And closer to what I think Simon was talking about. Leo and Regina, http://www.postgis.us -Original Message- From: postgis-users-boun...@postgis.refractions.net [mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of Simon Greener Sent: Thursday, August 05, 2010 4:02 AM To: PostGIS Users Discussion Subject: Re: [postgis-users] Search Engine Uli, Clearly, if you want to search across different tables you need a way to combine data in a common place. You should not do anything like search the tables one after the other and combine the results. There may be a software limitation in PostgreSQL that supports this as a technical decision but it is foolish to suggest that you should not do anything like search tables one after another. Hell, I did just this in SQL Server 2008 with 800 tables and the execution of the FULLTEXT SQL is very, very fast. That is 10 seconds. I filter the tables by MBR first against an enhanced Geometry_Columns table before using FULLTEXT to do the search. But it may mean that you mean selecting against the tables using ordinary SQL with all searchable columns in the where clause as predicates. Yes, this would be very slow and inflexible in terms of search capability. That is why specialist search structures and functionalty have been created for most databases. Even if you merge all tables into one, you will need some explicit mechanism (trigger!) to keep your tsvector up to date. Correct. This is one of the reasons why this approach is unsustainable. Also, what if someone didn't have the ability to modify the schema at will? It might be that a lot of the use of PostGIS is as a shapefile replacement, but real application databases do not afford that sort of happy go lucky approach to data structuring. A system using triggers to build the tsvector is not so hard to maintain. Once you have written the triggers it simply runs and runs. Any time data in any relevant table changes, a trigger updates the tsvector, some key (gid or whatever) and maybe other data like bounding boxes in the one and only table that will be searched. Some challenge could arise, if it takes too long to rebuild your index on the tsvector. But normally this is not critical. We use the trigger approach for our search engine on http://mapmatters.org . The hardest thing there was and still is to optimize the way how data are combined and weighted for the tsvector ( so how you feed the to_tsvector function). I do not know much about tsvector but if you can create it external to the data and populate it by triggers without otherwise changing the data structures of the database then this would be a good solution. In SQL Server 2008 FULLTEXT's indexing of tables as they change can be declaratively organised. But if this is not possible with tsvector then the use of triggers may be the way to go. regards Simon -- SpatialDB Advice and Design, Solutions Architecture and Programming, Oracle Database 10g Administrator Certified Associate; Oracle Database 10g SQL Certified Professional Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE, Manifold GIS, FME, Radius Topology and Studio Specialist. 39 Cliff View Drive, Allens Rivulet, 7150, Tasmania, Australia. Website: www.spatialdbadvisor.com Email: si...@spatialdbadvisor.com Voice: +61 362 396397 Mobile: +61 418 396391 Skype: sggreener Longitude: 147.20515 (147° 12' 18 E) Latitude: -43.01530 (43° 00' 55 S) GeoHash: r22em9r98wg NAC:W80CK 7SWP3 ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Search Engine
Uli, we should not drift too far into a discussion about how you would do it with SQL Server. This was not Ricardos question. But I admit I have to specify some of my comments to get clearer. That's true. My main point is not that SQL Server is good (far from it), is that one should try not to modify database structures just for something like text searching. Since the original posting gave an indication that this was about indexing Just A Bunch Of Tables (JBOT), he can do what you like, but if someone else was listening and they can't modify designs (a production application). decision but it is foolish to suggest that you should not do anything like search tables one after another. Hell, I did just this in SQL Server The point ist not only speed. The main reason is that you loose the ability of PostgreSQL's full text search capabilitites to rank your results. With separate tables you have to pick the n best matches of each table and combine them afterwards to display the overall n best matches. So, if I am looking for lapsed dog licenses I have to have let PostgreSQL rank a search against a license table against one against garbage pickup times? Perhaps one needs more business/functional information than just index and search a bunch of tables. Perhaps global ranking isn't needed. If it is, for all tables, then, perhaps, PostgreSQL's implementation might need changing. Also, and more importantly, Ricardo never mentioned the ranking of cross-table search results as required functionality. Perhaps another way would be to join the tables in a view and do the search on the view. But then you can't fully benefit from the index. Didn't Leo/Regina suggest functional indexes? Will they work? I don't know if SQL Server does not face these limitations? Anyway, 10 seconds is not really really fast - at least for a PostgreSQL database ;-) Now if you are on the fastest DB around (PostgreSQL) why would you say (in a previous email): You should not do anything like search the tables one after the other and combine the results. ;-) It is actually less than 5 seconds but I can't say exactly as I am not aware of the numbers in the production environment (so I pushed it up). But it is fronted by a client UI and I am told the customers are not complaining about waiting for a spatial/textual search against up to 800 tables. And you know what customers are like! I didn't mean anything technical but the problem, how to produce the most meaningful results and ranking of the results (how to weight values out of different fields, which words are relevant or only stop words...). The more important issue for comparison purposes is that there is no cross-800 table ranking (though in-table ranking, stop words etc can be done) and there is no need to modify database design. I will say no more about SQL Server 2008 as you are right it is not relevant. regards Simon -- SpatialDB Advice and Design, Solutions Architecture and Programming, Oracle Database 10g Administrator Certified Associate; Oracle Database 10g SQL Certified Professional Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE, Manifold GIS, FME, Radius Topology and Studio Specialist. 39 Cliff View Drive, Allens Rivulet, 7150, Tasmania, Australia. Website: www.spatialdbadvisor.com Email: si...@spatialdbadvisor.com Voice: +61 362 396397 Mobile: +61 418 396391 Skype: sggreener Longitude: 147.20515 (147° 12' 18 E) Latitude: -43.01530 (43° 00' 55 S) GeoHash: r22em9r98wg NAC:W80CK 7SWP3 ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Search Engine
Hi! one should try not to modify database structures just for something like text searching. Reality is that very often you cannot modify them (let alone being the db about GIS or not), because you have poorly documented legacy apps that rely on them. Or they are decently documented by you don't have the funding it takes to make the modification. But even if you could, you should NOT. A good structure has a certain design as a normalization goal. If a given technology (like text searching) is more efficient when fed denormalized data, then you make a controlled denormalization, which is usually maintained by triggers on an EXTERNAL entity (another table). In the end I have the impression that you and Uli are saying the same thing. Bèrto -- == Constitution du 24 juin 1793 - Article 35. - Quand le gouvernement viole les droits du peuple, l'insurrection est, pour le peuple et pour chaque portion du peuple, le plus sacré des droits et le plus indispensable des devoirs. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
