Аналогия будь она неладна!

[MadChild]

Здравствуйте.
Ломаю голову над следующим вопросом.
Имеется таблица в MySQL:

Код: Выделить всё

|КОД_ТОВАРА|НАЗВАНИЕ|
|Т276<Т176 | Фонарь |

Особенность кодов в том, что они имеют аналогию, то есть код Т176 аналогичен коду Т276. Сложность в составлении запроса, а именно в построении цепочки аналогий. Вот так: Т055 -> Т176 -> Т276 -> Т443.
В массиве построить такую аналогию можно, а вот как можно это сделать с помощью SQL запроса?

Возможно все сумбурно, уточню где нужно. Подскажите с алгоритмом пожалуйста.

P.S. Цепочка аналогий нужна для того, чтобы при вводе любого кода из цепочки можно было найти последний, более свежий.
Особенность в том, что далее в таблице аналогия прописана не Т443<Т176, а Т443<Т276. Не всю же аналогию прописывать.

[iGrok]

Я правильно понимаю, что в этой таблице хранится "история кодов товара"?
Если так, то почему не выделить под "новый код" отдельное поле, или вообще не хранить только новый код?

Теоретически, можно сделать так:

Код: Выделить всё

select `КОД_ТОВАРА` from `tablename` where `НАЗВАНИЕ` = (select `НАЗВАНИЕ` from tablename where `КОД_ТОВАРА` like '%_твой_код_%')
order by _id_или_время_добавления_ desc limit 1

_id_или_время_добавления_ - параметр, по которому определяется, какой код новее.

[alibek]

Никак.
Переделывай структуру таблиц.

[SLIM]

Или дополнить.
Нужна таблица, где будет на пять возможных кодов один единый, и приоритеты "старости"

Т.е. таблица типа
Код | ЕдиныйКод | Приоритет старости

Единый код объединяет несколько кодов в группу, а приоритет дает размерность по времени.
Ну вроде так. А вообще нужно серьезней думать.

[MadChild]

Если так, то почему не выделить под "новый код" отдельное поле, или вообще не хранить только новый код?

Хранение всей истории кодов нужно для того, чтобы при заказе клиентом "старого" кода, можно было провести аналогию на новый.
Новые коды обусловленны иными свойствами товаров: ценой, поставщиком и т.д.

[MadChild]

Или дополнить.
Нужна таблица, где будет на пять возможных кодов один единый, и приоритеты "старости"

Т.е. таблица типа
Код | ЕдиныйКод | Приоритет старости

Единый код объединяет несколько кодов в группу, а приоритет дает размерность по времени.
Ну вроде так. А вообще нужно серьезней думать.

На сколько я понял, картина получается такая:
Аналог | Основной код | Приоритет старости |
Т176 | Т055 | 1
Т276 | Т055 | 2
Т443 | Т055 | 3
Т276 | Т176 | 4
Т443 | Т176 | 5
Т443 | Т276 | 6

чем выше приоритет, тем новей код.
Как-то грамоздко получается, у нас более 4 тыс. наименований
и более половины с цепочками аналогов по 10-15.

[HandKot]

не совсем понял
у вас в поле "КОД ТОВАРА"
имеет всегда вид XXX<YYY
где XXX - аналог товара
YYY - код товара?

[MadChild]

не совсем понял
у вас в поле "КОД ТОВАРА"
имеет всегда вид XXX<YYY
где XXX - аналог товара
YYY - код товара?

Да.

[iGrok]

не совсем понял
у вас в поле "КОД ТОВАРА"
имеет всегда вид XXX<YYY
где XXX - аналог товара
YYY - код товара?

Да.

Мой способ ты так и не попробовал, надо понимать?

А чего громоздкого?
У тебя сколько данных было, столько и останется.
Ты одно поле разбиваешь на два и всё.
Плюс один байт идёт на счётчик "старения". Если есть возможность, что для какого-то товара будет более 255 вариантов кода - то два байта на счётчик.

А по-хорошему это вообще так делается:
В таблице с товаром остаётся только описание товара + внутренний суррогатный ключ - уникальный идентификатор товара.
Отдельно делается вторая таблица - соответствие кодов товара этому идентификатору.

Ну а потом из этого по любому коду товара можно легко получить идентификатор, а по идентификатору - последний код.

[SLIM]

А чего громоздкого?
У тебя сколько данных было, столько и останется.
Ты одно поле разбиваешь на два и всё.
Плюс один байт идёт на счётчик "старения". Если есть возможность, что для какого-то товара будет более 255 вариантов кода - то два байта на счётчик.

Прально прально. Справочник только расширится на несколько полей, не более.

А по-хорошему это вообще так делается:
В таблице с товаром остаётся только описание товара + внутренний суррогатный ключ - уникальный идентификатор товара.
Отдельно делается вторая таблица - соответствие кодов товара этому идентификатору.

Ну а потом из этого по любому коду товара можно легко получить идентификатор, а по идентификатору - последний код.

Нууу ты замутил. Так строятся базы на серверах нормальных, а не на dbf-ах. Хотя конечно это правильнее на все 100.

[iGrok]

Нууу ты замутил. Так строятся базы на серверах нормальных, а не на dbf-ах. Хотя конечно это правильнее на все 100.

DBF?? Какой ещё dbf? У него MySQL.

[VVitafresh]

А по-хорошему это вообще так делается:
В таблице с товаром остаётся только описание товара + внутренний суррогатный ключ - уникальный идентификатор товара.
Отдельно делается вторая таблица - соответствие кодов товара этому идентификатору.

Ну а потом из этого по любому коду товара можно легко получить идентификатор, а по идентификатору - последний код.

Подтверждаю.
Имел дело с базой поставщиков автозапчастей -- аналоги именно так и сделаны.

Основная таблица:

Код: Выделить всё

код товара, код замены (генерируемый уникальный ключ), описание товара

Таблица замен (аналогов):

Код: Выделить всё

код замены, код товара

MadChild, чтобы тебе было понятней -- твой пример:
Основная таблица:

Код: Выделить всё

T055, 11111111, описание
T176, 11111111, описание1
T276, 11111111, описание2
T443, 11111111, описание3
Txxx, 22222222, описание4

Таблица аналогов:

Код: Выделить всё

11111111, T055
11111111, T176
11111111, T276
11111111, T443

[iGrok]

Кстати, если по какой-то причине для чего-либо таблица должна остаться "с виду неизменной", то можно воспользоваться первым вариантом (разделение кодов на два поля), и сделать вьюшку (CREATE VIEW), в которой их обратно объединить.

[MadChild]

Всем большое спасибо.
Буду реализовывать. О результатах отпешусь.

[SLIM]

DBF?? Какой ещё dbf? У него MySQL.

О блин. А с каким это я топиком перепутал...мда. Извиняюсь.
VVitafresh ну да. Как то так. Впринципе то что я и говорил только с нормальным принципом построения базы, как говорил iGrok.

Кстати, если по какой-то причине для чего-либо таблица должна остаться "с виду неизменной", то можно воспользоваться первым вариантом (разделение кодов на два поля), и сделать вьюшку (CREATE VIEW), в которой их обратно объединить.

Ну если у него есть таблица которую он представил, то ему не избежать изменения. Хотя...можно таки дополнительно составить таблицу соответствий и подвязывать....ох, можно, но помоему так "геморно". Лучше нормальную структуру брать.

[MadChild]

DBF?? Какой ещё dbf? У него MySQL.

О блин. А с каким это я топиком перепутал...мда. Извиняюсь.
VVitafresh ну да. Как то так. Впринципе то что я и говорил только с нормальным принципом построения базы, как говорил iGrok.

Кстати, если по какой-то причине для чего-либо таблица должна остаться "с виду неизменной", то можно воспользоваться первым вариантом (разделение кодов на два поля), и сделать вьюшку (CREATE VIEW), в которой их обратно объединить.

Ну если у него есть таблица которую он представил, то ему не избежать изменения. Хотя...можно таки дополнительно составить таблицу соответствий и подвязывать....ох, можно, но помоему так "геморно". Лучше нормальную структуру брать.

Изменить структуру базы - это не так сложно. Учитывая тот факт, что осуществляется переход на MySQL. Скажу больше сейчас способ хранения информации, лично у меня, вызывает лихорадочные спазмы и нервный тик.
Представьте себе, имеется программа обработки заявок, информация о всех заявках, клиентах и т.д. храниться в файлах txt.
То есть: файл заявок - 47mb, файл клиентов - 24mb, ну и в таком духе. Мало того вся эта "бяка" из более чем 25 файлов загружается в многомерные массивы и "крутиться" в программе.
Вот к примеру:

Код: Выделить всё

Public Type Demand
Number As String
ClientCode As String
Where As String
Whom As String
IO As String
Phones As String
DayIn As Date
DayOut As Date
Mass As String
OrderNumber As String
SumIn As Long
SumOut As Long
OrderMethod As String
PayMethod As Byte
Comment As String
Form3 As String
Payed As Byte
Forwarded As Byte
Tarif As String
Sbor As String
Itogs As String
Itogo As String  ' Н/П
Dopl As String
OC As String
Goods As String
Container As Byte
Goback As Byte
ReestrNum As Long
ReturnComplete As Boolean
SendPlace As String
Rang As Double
Grad As Double
DayBack As Date
DayPay As Date
PackerNumber As Byte
Barcode As String
Printed As Boolean
Glass As Boolean
Prize As Long
AviaFrom As String
End Type
Public Demands(100000) As Demand


Вот такой геморой. Который я планомерно перевожу на SQL.

[SLIM]

Вот это да!!!
Видел я такую базу как-то. Но так хоть как-то смешанно работала с txt и dbf. А тут...жуть. Я думал такого уже не существует.