Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Подскажите, пожалуйста
|
|||
|---|---|---|---|
|
#18+
Есть две таблицы, в 1-й слова и указатель на мемо-поле, в котором находяться шифры через пробел. А во 2-й - шифры и описания шифров. Необходимо задать поиск, в котором бы по слову, выходили бы шифры и описания. Возможно ли такое? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2003, 18:26 |
|
||
|
Подскажите, пожалуйста
|
|||
|---|---|---|---|
|
#18+
Если речь идет о запросе, то для этого хотелось бы иметь дело с нормализованной структурой бд: Код: plaintext 1. 2. 3. 4. 5. Тогда запрос запишется естественным для реляционной базы образом: Код: plaintext 1. 2. 3. 4. Если все же нужен специализированный механизм, то в этом случае ничего другого не остается, как использовать старый дедовский способ: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2003, 21:33 |
|
||
|
Подскажите, пожалуйста
|
|||
|---|---|---|---|
|
#18+
Все бы хорошо, да только слов в таблице около двух тысяч, а шифров более 30 тысяч! И средствами SQL поиск слова будет занимать очень много времени. А это не приемлемо. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2003, 13:09 |
|
||
|
Подскажите, пожалуйста
|
|||
|---|---|---|---|
|
#18+
Я не совсем понял задачу. Нельзяли по паре строк из каждой таблицы привести и показать что именно должно быть на выходе. А вообще-то 30 тыс х 2 тыс = 60 млн. - это не так уж и много. Вы забываете, что есть такое понятие как "оптимизация". Так что в случае нормализованной структуры всегда (ну или почти всегда :) ) можно так оптимизировать запрос, что время выполнения будет относительно невелико. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2003, 14:43 |
|
||
|
Подскажите, пожалуйста
|
|||
|---|---|---|---|
|
#18+
первая таблица выглядит так: слово вхождения земляные memo разработка memo мемо поля выглядят так: Е51-1-2 Е51-1-3 Е51-1-4 Е51-1-5 Е51-1-6 Е51-1-7 Е51-2-1 Е51-2-2 Е51-2-3 Е51-2-4 Е51-5-1 Е51-5-2 Е51-1-1 Е01-01-001-2 Е01-01-001-3 Е01-01-001-4 вторая таблица: шифр наименование ед. измерения оплата Е51-1-2 Разработка грунта 100 м.куб. 100 руб Е51-1-3 Изменение уровня 100 м.куб. 200 руб в конечном итоге нужно, сравнить слово из запроса пользователя со словами из 1-й таблицы, выгрести из мемо-полей шифры в столбец, с обозначением. что они означают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2003, 18:13 |
|
||
|
Подскажите, пожалуйста
|
|||
|---|---|---|---|
|
#18+
При такой организации структуры хранения через запрос ничего не получится. Но все не так плохо. Начиная с 6 версии FoxPro появилась такая функция ALINES(), так что можно слегка модифицировать код приведенный Анатолием примерно так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Разумеется, размерность поля Shifr во временной таблице, должна быть такой же как и размерность поля code в таблице содержащей расшифровку. Но строго говоря, очень неразумная организация базы данных. По крайней мере я вижу 2 приницпиальные ошибки, которые приведут к большим проблемам в будущем: 1) Список шифров загнали в мемо-поле вместо таблицы-посредника 2) Если я правильно понял, то в качестве ключевого поля используется не код записи (суррогатный ключ), а шифр (естесственный ключ). А это приведет к большим проблемам в случае модификации шифров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2003, 18:39 |
|
||
|
|

start [/forum/topic.php?fid=41&msg=32278780&tid=1597806]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
51ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
34ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 344ms |

| 0 / 0 |
