signo google funciona como comandos busqueda avanzada .net database tsql design ado.net

.net - google - comandos de busqueda signo+



Localización de base de datos-Listas de búsqueda-forma más inteligente (3)

Estoy buscando agregar algunas listas de búsqueda en la base de datos, pero quiero que sean fáciles de ubicar (SQL 2005, ADO.NET)

Esto incluiría:

  • Fácil manejo de múltiples idiomas al mismo tiempo
  • Recuperación fácil de valores de la base de datos
  • Lenguaje alternativo (en caso de que falte el idioma seleccionado)

Estaba pensando en tener una tabla que almacenara la lista de búsqueda en varios idiomas (usando para diferentes idiomas el mismo ID) y use una función que devolvería el valor de la lista de búsqueda al recibir el ID y el Idioma.

Una de las trampas sería que tengo que agregar manualmente un parámetro de idioma a cada consulta que utiliza la lista de búsqueda.

Estoy buscando una solución que me permita enviar el parámetro como una "variable de sesión / global", o que envíe el parámetro automáticamente con la consulta sql, y la función para recuperarlo por sí mismo (ya sea para adjuntar el parámetro automáticamente) , ya sea para poder leer el parámetro).

La solución puede verse más o menos así, pero no me importa si es diferente, siempre que no proporcione explícitamente el parámetro a la consulta (pseudocódigo):

1. Send the language using "the method" 2. Execute Query 3. Get the localized results

Aclaración:

  1. Normalmente, la consulta se vería así (recuerde usar la función de búsqueda):

    SELECT .., GetLookupList1(lookup_ID, language), .. FROM TABLE

GetLookupList1 es una función definida por el usuario que recupera el valor de búsqueda para una tabla de búsqueda. Al usar esta función, el Código SQL es más fácil de leer y mantener.

El cuerpo de la función sería algo así como:

SELECT @result = LookupValue FROM LookupTable1 WHERE ID=@Lookup_ID and Language=@lang RETURN @result

  1. Lo que quiero es poder eliminar el parámetro de idioma de la función a algún tipo de variable estática, disponible solo para la conexión / instrucción / comando actual, para que la consulta se vea como

    SELECT .., GetLookupList1(lookup_ID), .. FROM TABLE


Como no hay variables globales definidas por el usuario en SQL Server, deberá usar uno de dos enfoques:

  1. Tablas - temporales o permanentes. Ejemplo con tablas permanentes: http://weblogs.sqlteam.com/mladenp/archive/2007/04/23/60185.aspx .
  2. SET CONTEXT_INFO: http://msdn.microsoft.com/en-us/library/ms187768.aspx . Context_info le permite asociar 128 bytes binarios a una sesión / conexión. Funciona, pero ten cuidado. Si adquiere el hábito de usarlo, corre el riesgo de sobrescribirlo accidentalmente en otro contexto. Solo hay uno por sesión / conexión.

Ejemplo context_info t-sql:

declare @languagein varchar(30), @contextin varbinary(128), @languageout varchar(30), @contextout varbinary(128) select @languagein = ''ro-RO'' select @contextin = cast(@languagein as varbinary(128)) set context_info @contextin --do whatever you like here: queries, stored procs. --context_info stays ''ro-RO'' for the duration of the session/connection select @contextout = context_info() set @languageout = replace(cast(@contextout as varchar(30)),0x00, '''') print @languageout

Otra técnica que he usado en la localización es una combinación de tres partes para asegurar un resultado. Verifique primero la región del idioma, luego el idioma y luego un valor predeterminado. Según su consulta:

SELECT COALESCE(langregion.LookupValue, lang.LookupValue, fallback.LookupValue) LookupVal FROM LookupTable1 fallback LEFT OUTER JOIN LookupTable1 lang ON lang.ID = fallback.ID AND lang.Lang = @language LEFT OUTER JOIN LookupTable1 langregion ON langregion.ID = fallback.ID AND langregion.Lang = @languagewithregion WHERE fallback.ID = @Lookup_ID AND fallback.Lang = @defaultlanguage


Después de estudiar el problema en detalle, he encontrado lo siguiente:

  1. Podría usar SET CONTEXT_INFO , pero tendría que inyectar algunos SQL para resolver el problema.

  2. La mejor opción sería no almacenar datos localizados en las tablas de búsqueda. En su lugar, almacene algunas cadenas de identificación y use la lógica de localización personalizada en la aplicación para hacer coincidir las cadenas con los datos localizados. Para .NET Framework, se implementaría mediante el uso de recursos, con un proveedor de recursos personalizado si quiero recuperar información localizada de un databse.

Gracias por sus respuestas.


Si estructuras tus datos de esta manera:

MessageToken DisplayText LangCode firewood Fire wood en firewood Bois de chauffage fr

Cuando realice su consulta, solo proporcione el ID de idioma predeterminado (si está en blanco) o el ID de idioma proporcionado. Use una lista estándar de tokens para los mensajes.

Select DisplayText from (some table) where MessageToken = ''firewood'' and LangId = ''en''